Building meta-ros for Intel Architecture

Hello everyone,

I’ve recently been working with the meta-ros layer, and I’ve been able to get it up and running on a Raspberry Pi running Wind River Linux. So far, I’ve ported the Turtlebot 3 software, ROS performance tests, and Colcon buildtool to new layers, and these should hopefully be made public soon.

I have now been attempting to build meta-ros for the AAEON UP board. I’ve been trying to get it working with as few changes to meta-ros as possible, but I’ve run into an issue: while {libdir} in Bitbake is set to /usr/lib for Raspberry Pi, 64-bit x86 boards use /usr/lib64 instead. This is problematic, as there are a number of ROS libraries which are hardcoded to install to the /usr/lib directory; see [https://github.com/ros2/rosidl/blob/master/rosidl_generator_c/CMakeLists.txt](https://github.com/ros2/rosidl/blob/master/rosidl_generator_c/CMakeLists.txt) for an example of what I mean. Bitbake, by default, will not automatically package libraries installed to /usr/lib when {libdir} is /usr/lib64, which results in a number of build-time issues.

I was hoping I could see if anyone else has tried to build meta-ros on Intel architecture, and whether you’ve run into this same problem. Clearly there are a number of simple but hacky fixes that could solve this, but I figured it would be a good idea to highlight this issue on a public forum, so that a more robust solution could potentially be integrated into the official meta-ros layer.

1 Like

UPDATE:
It turns out this problem is a little bit more complicated than I originally assumed. Due to the inconsistency in the way different packages handle library inclusions, simply packaging all libraries installed under /usr/lib will not fix the issue. For example, some modules which depend on a library that gets packaged into /usr/lib will only look in /usr/lib64, and vice versa. It looks like the only blanket solution is to manually change the board tune config files to use /usr/lib as the lib directory instead of /usr/lib64. I dislike having to do this, as it could complicate 64-bit vs. 32-bit library distinctions, and may cause system issues. For now, though, this fix will get meta-ros working on x86 architecture.