Due to my maintenance activities of the meta-ros layer, I noticed that in updated boost 1.63 [1] the python PACKAGECONFIG leads to a compilation error. With the update from boost 1.62 to 1.63 (openembedded-core commit ef603f41b5df4772bb598ec9d389dd5f858592afef603f41b5df4772bb598ec9d389dd5f858592af@openembedded/openembedded-core) [1], bitbake boost fails during do_compile. It fails with meta-ros probably due to appending PACKAGECONFIG with python in the boost_%.bbappend file [2]. The tested build configuration is: Build Configuration: BB_VERSION = "1.33.2" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "fedora-23" TARGET_SYS = "i586-oe-linux" MACHINE = "qemux86" DISTRO = "nodistro" DISTRO_VERSION = "nodistro.0" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta = "HEAD:ef603f41b5df4772bb598ec9d389dd5f858592af" meta-oe meta-python meta-multimedia = "master:1dff2351aa6cdafa5a501e8956cb853ab17ed9ae" meta-qt4 = "master:2c7f8df9039be498f8a2232d1428adb7f4e5e800" meta-ros = "rojkov-drop-librealsense-v1:fe4f0c1c2b3608306c981e61ca60674b46763911" The full error log is at https://gist.github.com/bulwahn/9d27142d8a39f6573b0e2e6f031f9839. I did not do any further failure analysis yet. You also find this issue tracked in the meta-ros issue tracker [3]. [1] http://cgit.openembedded.org/openembedded-core/commit/?id=ef603f41b5df4772bb598ec9d389dd5f858592af [2] https://github.com/bmwcarit/meta-ros/blob/master/recipes-support/boost/boost_%25.bbappend [3] https://github.com/bmwcarit/meta-ros/issues/460
Created attachment 3649 [details] Full compile log It seems the log at gist.github.com got truncated. I've reproduced the failure and attached the full log to this bug. The problem seems to be an usual leak of host environment to bitbake: > "i586-oe-linux-g++" "-m32" "-march=i586" "-Wl,-O1" "-Wl,--hash-style=gnu" "-Wl,--as-needed" "--sysroot=/home/rojkov/work/ros/build/tmp-glibc/work/i586-oe-linux/boost/1.63.0-r1/recipe-sysroot" -ftemplate-depth-128 -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/rojkov/work/ros/build/tmp-glibc/work/i586-oe-linux/boost/1.63.0-r1=/usr/src/debug/boost/1.63.0-r1 -fdebug-prefix-map=/home/rojkov/work/ros/build/tmp-glibc/work/i586-oe-linux/boost/1.63.0-r1/recipe-sysroot-native= -fdebug-prefix-map=/home/rojkov/work/ros/build/tmp-glibc/work/i586-oe-linux/boost/1.63.0-r1/recipe-sysroot= -fvisibility-inlines-hidden -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -I"/home/rojkov/work/ros/build/tmp-glibc/work/i586-oe-linux/boost/1.63.0-r1/recipe-sysroot/usr/include/python2.7" -I"/usr/lib64/python2.7/site-packages/numpy/core/include" -c -o "/home/rojkov/work/ros/build/tmp-glibc/work/i586-oe-linux/boost/1.63.0-r1/boost_1_63_0/i586-oe-linux/boost/bin.v2/libs/python/build/aca09349fdb84d131321425f6c3a38ed/numpy/dtype.o" "libs/python/src/numpy/dtype.cpp" For some reason the command includes the option > -I"/usr/lib64/python2.7/site-packages/numpy/core/include" and defining > --sysroot=/home/rojkov/work/ros/build/tmp-glibc/work/i586-oe-linux/boost/1.63.0-r1/recipe-sysroot doesn't seem to help to ignore it. As result libs/python/src/numpy/dtype.cpp gets compiled against the system python2-numpy. If python2-numpy is removed from the host then boost builds correctly.
Boost seems to think that building in a prefix or dare I say it cross-compiling is stupid, so really doesn't handle this well. What's happening is that it's finding a python in $PATH and then hunting around for bits it can link against, finding some of numpy on your host, and then being surprised when it can't link against a numpy in the sysroot. This is basically a duplicate of #11104 although breaking differently. I just sent a patch to oe-core so that if python is enabled, it is told explicitly to build against the sysroot python3 and won't try anything else. This should stop it looking for host numpy... *** This bug has been marked as a duplicate of bug 11104 ***