The script environment_cache.py generates a cache file that
sets LD_LIBRARY_PATH so that the paths to target libs
go first. This confuses native python3 which dynamically links
to the target libpython3 and that leads to wrong linking
of dynamic python modules:
04:09:43 | [ 16%] Generating Python from MSG std_msgs/Float32
04:09:43 | catkin_generated/env_cached.sh /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot-native/usr/bin/python3-native/python3 /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/share/genpy/cmake/../../../lib/genpy/genmsg_py.py /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/std_msgs-0.5.10/msg/Float32.msg -Istd_msgs:/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/std_msgs-0.5.10/msg -p std_msgs -o /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/build/devel/lib/python3.5/site-packages/std_msgs/msg
04:09:43 | Traceback (most recent call last):
04:09:43 | File "/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/share/genpy/cmake/../../../lib/genpy/genmsg_py.py", line 44, in <module>
04:09:43 | import genpy.generator
04:09:43 | File "/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/lib/python3.5/site-packages/genpy/__init__.py", line 34, in <module>
04:09:43 | from . message import Message, SerializationError, DeserializationError, MessageException, struct_I
04:09:43 | File "/srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot/opt/ros/indigo/lib/python3.5/site-packages/genpy/message.py", line 40, in <module>
04:09:43 | import math
04:09:43 | ImportError: /srv/jenkins/workspace/builder-slot-0/build/tmp-glibc/work/corei7-64-refkit-linux/std-msgs/0.5.10-r0/recipe-sysroot-native/usr/lib/python3.5/lib-dynload/math.cpython-35m-x86_64-linux-gnu.so: undefined symbol: _Py_dg_stdnan
Don't put LD_LIBRARY_PATH to the cache, but use the value provided
by bitbake.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
By default meta-ros uses python2. In case you want to get
python3-compatible builds add the following line to your local.conf:
ROS_USE_PYTHON3 = "yes"
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
If a package (A) depends on another package (B) and the package
B depends on Boost then it might happen that B produces BConfig.cmake
file where absolute paths to Boost's headers are put (because CMake's
standard FindBoost.cmake module reports absolute paths). In case of
Yocto it means that BConfig.cmake will contain something like
/path/to/build/tmp-glibc/work/i586/package_B/0.0.1/recipe-sysroot/usr/include.
The path may not exist at the moment when the package A is being built.
And that leads to the failure of the check this patch switches off.
The problem has been reported to catkin's issue tracker:
https://github.com/ros/catkin/issues/851
This patch "relocates" required headers from dependencies' sysroots
to the current sysroot by removing sysroot prefix from include dirs
in *Config.cmake files at the moment the files get created and
by prepending the include dirs again with the current sysroot prefix.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
The patch added in the reverted commit was meant to fix the issue
https://github.com/bmwcarit/meta-ros/issues/291
In fact it enables CMake to look for libraries in a host system which
leads to errors when a path is tested for a library presence with the
help of CMake's find_library() command: e.g. a non-existing host
directory is tested for library presence and find_library() returns
successfully because the library exists in bitbake's sysroot; then the
directory is used by the linker, but the library doesn't exist in the
directory -> failure. In worse cases the host directory may actually exist
and contain the library, but of wrong architecture, format or
incompatible ABI making finding the root cause a difficult task.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
In _setup_util.py.in, we use python provided by environment instead of
the generated one, as the generated python path can be arbitrarily long
(depending on the location of the build directory), and hence reaches
the shebang line limit, causing the script to fail at start-up.
The catkin developers changed the cmake-generated template _setup_util.py
to use @PYTHON_EXECUTABLE@ instead of /usr/bin/env python in changeset
bf12b40c2 [1]. We revert this change here to address the issue #384 [2].
[1] bf12b40c2a
[2] https://github.com/bmwcarit/meta-ros/issues/384
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
On the meta-ros issue tracker, the issue #291 reports a
linking problem with rosconsole if ROS Hydro is also installed
on the host system. Kristof investigated in that, and published
a patch [1] on September 27th, 2014, which resolved the rosconsole
issue, but showed issues with urdfdom.
After reading through the discussion of issue #291, I started
initial testing with Kristof's patch. After testing Kristof's
patch, I also investigated the urdfdom problem, and came up with
the solution to revert the part of his patch, which moved
`-DCMAKE_INSTALL_PREFIX:PATH='${ros_prefix}'` to ros.bbclass.
Initially, I believed that the issue that was addressed with
the second part of Kristof's patch, has been resolved with
commit 7e2eb25e51. However,
the issue remains, but is only reproducible with the Ubuntu
saucy distribution.
On my first local setup, I could reproduce the issue #291 with
rosconsole on commit 47eab4263c.
After applying this commit, the issue with rosconsole did not
occur anymore on a clean fresh build.
`bitbake packagegroup-ros-world` did not show any other further
issues.
On my second local setup, on a newly-installed Ubuntu 12.04
(precise) system, I checked that the proposed commit resolves
some linking problems to boost, with some latest
OpenEmbedded-Core repository and the poky-dizzy distribution.
A detailed report of the investigation of this second local
setup is at my Github Gist [2].
In the first review of the pull request #318, Kristof noticed
that on an Ubuntu 13.10 (saucy), an issue with message-filters
still occurs. I could not reproduce this and other reported
errors on the Ubuntu 12.04 system, so I believe certain errors
only appear on certain Ubuntu distributions, which makes them
difficult to pinpoint. Therefore, we decided to defer the
resolution of this problem with Ubuntu 13.10.
To adjust to the concurrent work in pull request #319, during
the rebasing, the patch has been moved from the catkin directory
to the files directory.
Kristof remains the author of the applied patch, as I have not
modified the patch. I have put myself as this author's commit,
as I take the responsibility of the modifications compared to
Kristof's original work and I have tested this commit in my
test setting.
[1] 9ff76ffb7a
[2] https://gist.github.com/bulwahn/a8d5b7c27550b399f866
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
catkin: move to files directory (fixup)
The catkin package has got a runtime dependency to cmake, make,
gcc and other build utilities. These dependencies, however, are
only needed if it is desired to build with catkin on the target
board. If we do not want to build on the target board, i.e., if
we just want to use ros tools like roslaunch, only a small part
of catkin (i.e., the corresponding python packages) is required
to be deployed on the target board.
Therefore, we introduce a new package called catkin-runtime.
It installs only the python packages that are required for
the ros tools to run. The roslib package now depends on
catkin-runtime (previously: catkin).
I also tried an alternative approach which just modifies catkin.bb:
- add a catkin-runtime package
- move PYTHON_SITEPACKAGES_DIR from FILES_catkin to FILES_CATKIN_RUNTIME
- make catkin_runtime RDEPEND on the python stuff
- make catkin RDEPEND on the cmake, binutils, ..., + catkin-runtime
With this setup, for some reason, bitbake thinks that
catkin-runtime still RDEPENDS on binutils. Therefore, I split up
the catkin recipe into two different recipes. Here, the
RDEPENDS are managed correctly.
If we want to deploy catkin as a build tool on the board, we can
simply add a runtime dependency to catkin. However, this should
not be the default setup.
Special thanks go to Tobias Henkel (tobias.henkel@bmw-carit.de)
who deserves most of the credits for this patch.
Signed-off-by: Andreas Baak <andreas.baak@bmw-carit.de>
Martin Jansa