Packaging in cross-compiling environment
Hey all, A few days ago I got around to updating an embedded Linux image (cross-compiled with openembedded[1]). Unfortunately, I soon hit a some realized that the latest Boost version in OpenEmbedded is 1.41. I initially thought it was quite strange that such a well-used library could be so out-of-date and thought I might try my hand at getting 1.45 running. I quickly found that the reason OE's package is so old is because they are using the Boost CMake fork, which hasn't been updated for some time. At first I found it strange that the packagers would use an alternative build system like this, but this is before I met bJam. Unfortunately, bJam has made what should have been a straightforward version bump one of the most unpleasant packaging experiences I have ever had. After much pain, I finally have a user-config.jam[2] capable of starting the build, but it quickly fails with a variety of compile errors. The first is related to icu, the test program for which fails during linking, gcc.link bin.v2/libs/regex/build/gcc-target/debug/has_icu bin.v2/libs/regex/build/gcc-target/debug/has_icu_test.o: In function `main': /home/bgamari/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/boost-1.45.0-r9.1/boost_1_45_0/libs/regex/bu ild/has_icu_test.cpp:24: undefined reference to `u_charFromName_4_2' collect2: ld returned 1 exit status "arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "- L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/O E/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interw ork" "-mno-thumb" -L"/usr/lib" -Wl,-R -Wl,"/usr/bin" -Wl,-R -Wl,"/usr/lib" -Wl,-rpath-link -Wl,"/usr/lib" -o "b in.v2/libs/regex/build/gcc-target/debug/has_icu" -Wl,--start-group "bin.v2/libs/regex/build/gcc-target/debug/ha s_icu_test.o" -Wl,-Bstatic -Wl,-Bdynamic -licuuc -licui18n -licudata -Wl,--end-group -g -L/home/bgamari/OE/an gstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib This appears to due to the build having used the icu 4.2 headers from /usr which is given as --includedir (which should be the install directory, according to the documentation) yet for is for some reason added to the include path list, "arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "-L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-a ngstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interwork" "-mno-thumb" -ftemplate-depth-128 -isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -O0 -fno-inline -Wall -pedantic -g -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I"." -I"/usr/include" -c -o "bin.v2/libs/regex/build/gcc-target/debug/has_icu_test.o" "libs /regex/build/has_icu_test.cpp" This causes the system's icu headers to override the cross-compile environment's, wrecking havoc when it comes to link time. Does anyone know why bJam is doing this? The second pertains to Python. I have specified a python configuration listing the correct include and library paths in my user-config.jam yet it appears that bjam ignores it "arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "- L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/O E/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interw ork" "-mno-thumb" -ftemplate-depth-128 -isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gn ueabi/usr/include -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_ SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/python/build/gcc-target/release/threading-multi/numeric.o" "libs/pyth on/src/numeric.cpp" ...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/numeric.o... gcc.compile.c++ bin.v2/libs/math/build/gcc-target/release/threading-multi/sph_neumannf.o gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/list.o In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/list.hpp:8, from libs/python/src/list.cpp:5: ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory compilation terminated. As indicated in the documentation, I have tried passing target-os=linux/python=2.6 to bjam but this does not appear to change bjam's behavior at all. When the build process begins, bjam produces this cryptic hint, error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched next alternative: required properties: <python>2.6 <target-os>linux matched error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched next alternative: required properties: <python>2.6 <target-os>linux matched Does anyone know what might be going on here? I seriously hope that the Boost project will consider dropping this seriously deficient, clunky, and user-unfriendly build system. When it works people will largely overlook its flaws, but most everyone I've heard who have actually worked with it seem to agree: stay away at all costs. I now completely understand why OpenEmbedded used the CMake fork. Cheers, - Ben [1] http://www.openembedded.org/ [2] user-config.jam using gcc : host : : <cxxflags> <linkflags> ; using gcc : target : arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=soft fp -L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/bgamar i/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu -mthumb-interwork -mno-thumb : <cxxflags>-isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/includ e -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb2 -isystem/home/bgamari/OE/angstro m-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-fr ame-pointer -O2 -ggdb2 -fpermissive -fvisibility-inlines-hidden <linkflags>-L/home/bgamari/OE/angstrom-dev/sysr oots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstr om-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu ; using python : 2.6 : python2.6 : /home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6 : /home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib ;
Ben Gamari wrote:
gcc.link bin.v2/libs/regex/build/gcc-target/debug/has_icu bin.v2/libs/regex/build/gcc-target/debug/has_icu_test.o: In function `main': /home/bgamari/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/boost-1.45.0- r9.1/boost_1_45_0/libs/regex/bu ild/has_icu_test.cpp:24: undefined reference to `u_charFromName_4_2' collect2: ld returned 1 exit status
"arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "- L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/O E/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interw ork" "-mno-thumb" -L"/usr/lib" -Wl,-R -Wl,"/usr/bin" -Wl,-R -Wl,"/usr/lib" -Wl,-rpath-link -Wl,"/usr/lib" -o "b in.v2/libs/regex/build/gcc-target/debug/has_icu" -Wl,--start-group "bin.v2/libs/regex/build/gcc-target/debug/ha s_icu_test.o" -Wl,-Bstatic -Wl,-Bdynamic -licuuc -licui18n -licudata -Wl,--end-group -g -L/home/bgamari/OE/an gstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
This appears to due to the build having used the icu 4.2 headers from /usr which is given as --includedir (which should be the install directory, according to the documentation) yet for is for some reason added to the include path list,
"arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "-L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-a ngstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interwork" "-mno-thumb" -ftemplate-depth-128 -isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -O0 -fno-inline -Wall -pedantic -g -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I"." -I"/usr/include" -c -o "bin.v2/libs/regex/build/gcc-target/debug/has_icu_test.o" "libs /regex/build/has_icu_test.cpp"
First, you can use -sICU_PATH=/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux- gnueabi/usr/ to specify where ICU is to be found and checked. Second, you can use -I, as opposed to -isystem, to specify headers for your sysroot, so that it is searched before -I/usr added by default value of -sICU_PATH.
The second pertains to Python. I have specified a python configuration listing the correct include and library paths in my user-config.jam yet it appears that bjam ignores it
"arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "- L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/O E/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interw ork" "-mno-thumb" -ftemplate-depth-128 -isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gn ueabi/usr/include -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_ SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/python/build/gcc-target/release/threading-multi/numeric.o" "libs/pyth on/src/numeric.cpp"
...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/numeric.o... gcc.compile.c++ bin.v2/libs/math/build/gcc-target/release/threading-multi/sph_neumannf.o gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/list.o In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/list.hpp:8, from libs/python/src/list.cpp:5: ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory compilation terminated.
As indicated in the documentation, I have tried passing target-os=linux/python=2.6 to bjam
What documentation is that? Although I kinda understand what this syntax is telling Boost.Build, I am totally confused as to why you might want to do that.
but this does not appear to change bjam's behavior at all. When the build process begins, bjam produces this cryptic hint,
error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched
Please run with --debug-configuration. This should print absolute paths to user-config.jam, site-config.jam and project-config.jam that are being loaded. Examine them to make sure only your user-config.jam configures Python. Let me know if this hlps. - Volodya
Thank you very much for your quick response. I greatly appreciate it. On Sat, 25 Dec 2010 10:42:15 +0300, Vladimir Prus <vladimir@codesourcery.com> wrote:
First, you can use -sICU_PATH=/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux- gnueabi/usr/ to specify where ICU is to be found and checked.
Ahh hah! Thanks. Problem solved. Are these options documented anywhere?
As indicated in the documentation, I have tried passing target-os=linux/python=2.6 to bjam
What documentation is that? Although I kinda understand what this syntax is telling Boost.Build, I am totally confused as to why you might want to do that.
http://www.boost.org/doc/libs/1_36_0/libs/python/doc/building.html Although I might be misunderstanding this as the link that I think is supposed to clarify the vague comment seems to be broken.
but this does not appear to change bjam's behavior at all. When the build process begins, bjam produces this cryptic hint,
error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched
Please run with --debug-configuration. This should print absolute paths to user-config.jam, site-config.jam and project-config.jam that are being loaded. Examine them to make sure only your user-config.jam configures Python. Let me know if this hlps.
Ahh, it seems that bootstrap.sh autogenerates project-config.jam, including a directive for the python configuration. This seems to be overriding user-config.jam. As it turns out, a path-constant directive for ICU_PATH is also present in this file. Is there some way to set the configuration file precedence such that user-config overrides project-config? It seems like this should be the case by default, if we are going to automatically generate project-config in bootstrap.sh. Otherwise packagers have to resort to sed'ing out lines which don't reflect their desired configuration. I commented out all but the correct 'using python' directive, using python : 2.6 : /home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr ; and the build system seems to have the right idea, notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter command: "/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/bin/python2.6" notice: [python-cfg] include path: "/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6" notice: [python-cfg] library path: "/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/python2.6/config" "/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" yet the build still fails, gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/list.o "arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "-L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-a ngstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interwork" "-mno-thumb" -ftemplate-depth-128 -isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -O3 -finline-fu nctions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/python/build/gcc-target/release/threadi ng-multi/list.o" "libs/python/src/list.cpp" In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/list.hpp:8, from libs/python/src/list.cpp:5: ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory compilation terminated. ...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/list.o... It seems that the build system knows the correct include path, but for some reason neglects to add it to the compiler command line. Any ideas? - Ben
Here is a complete (bzipped) build log in case it helps (with --debug-configuration). Cheers, - Ben
At Sat, 25 Dec 2010 11:26:18 -0500, Ben Gamari wrote:
In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/list.hpp:8, from libs/python/src/list.cpp:5: ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory
It's unable to find the Python headers. Do you have python26-dev (or whatever the package is called on your system) installed? You might also be interested in the initial output from bjam when you pass --debug-configuration to it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sun, 26 Dec 2010 10:03:05 -0900, Dave Abrahams <dave@boostpro.com> wrote:
At Sat, 25 Dec 2010 11:26:18 -0500, Ben Gamari wrote:
In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/list.hpp:8, from libs/python/src/list.cpp:5: ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory
It's unable to find the Python headers. Do you have python26-dev (or whatever the package is called on your system) installed? You might also be interested in the initial output from bjam when you pass --debug-configuration to it.
Yes, the headers are installed. This is an embedded cross-compilation environment, so entire packages are installed into a root on the host. As I mentioned in my last message, it seems that bjam knows where the headers are located, but this directory never makes it into the compiler command-line. I've looked through tools/build/v2/ trying to figure out where this is supposed to happen but jam may as well be Greek to me. See the attached (bzipped) log. - Ben
At Sun, 26 Dec 2010 14:37:01 -0500, Ben Gamari wrote:
On Sun, 26 Dec 2010 10:03:05 -0900, Dave Abrahams <dave@boostpro.com> wrote:
At Sat, 25 Dec 2010 11:26:18 -0500, Ben Gamari wrote:
In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/list.hpp:8, from libs/python/src/list.cpp:5: ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory
It's unable to find the Python headers. Do you have python26-dev (or whatever the package is called on your system) installed? You might also be interested in the initial output from bjam when you pass --debug-configuration to it.
Yes, the headers are installed. This is an embedded cross-compilation environment, so entire packages are installed into a root on the host. As I mentioned in my last message, it seems that bjam knows where the headers are located, but this directory never makes it into the compiler command-line.
Reading your previous message... Hmm, I see. So /home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6/pyconfig.h is a file on your system? I'm without a clue here, sorry. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sun, 26 Dec 2010 15:12:18 -0900, Dave Abrahams <dave@boostpro.com> wrote:
Reading your previous message...
Hmm, I see.
So /home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6/pyconfig.h is a file on your system?
Yes. Again, it seems that the problem is that the python include path never appears in the compiler command line.
I'm without a clue here, sorry.
Fair enough, thanks for your help! - Ben
On Sat, 25 Dec 2010 10:42:15 +0300, Vladimir Prus <vladimir@codesourcery.com> wrote:
Ben Gamari wrote:
but this does not appear to change bjam's behavior at all. When the build process begins, bjam produces this cryptic hint,
error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched
Please run with --debug-configuration. This should print absolute paths to user-config.jam, site-config.jam and project-config.jam that are being loaded. Examine them to make sure only your user-config.jam configures Python. Let me know if this hlps.
As I mentioned in later messages, --debug-configuration shows that the python include path is correctly determined but unfortunately is not included in the include paths given to the compiler? Where exactly is are the python include paths incorporated into the compiler command line? The only reference I can find is in tools/build/v2/tools/python.jam around line 900 but it's really not at all clear what happens to usage-requirements after this. Is there any document describing the inner workings of this build system that someone only familiar with more traditional build systems (autotools, make) might understand? I would really appreciate your input here. At this point I'm pretty lost and it would be very nice if openembedded (a very widely used environment in the embedded world) supported a reasonably up-to-date version of boost (if for no other reason than 1.41 has some very unfortunate bugs which make boost completely unusable for my application). Not to mention, I've spent altogether far too much time on this project to give up to a solvable build system issue. Thanks, - Ben
Ben Gamari wrote:
On Sat, 25 Dec 2010 10:42:15 +0300, Vladimir Prus <vladimir@codesourcery.com> wrote:
Ben Gamari wrote:
but this does not appear to change bjam's behavior at all. When the build process begins, bjam produces this cryptic hint,
error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched
Please run with --debug-configuration. This should print absolute paths to user-config.jam, site-config.jam and project-config.jam that are being loaded. Examine them to make sure only your user-config.jam configures Python. Let me know if this hlps.
As I mentioned in later messages, --debug-configuration shows that the python include path is correctly determined but unfortunately is not included in the include paths given to the compiler?
Where exactly is are the python include paths incorporated into the compiler command line? The only reference I can find is in tools/build/v2/tools/python.jam around line 900 but it's really not at all clear what happens to usage-requirements after this. Is there any document describing the inner workings of this build system that someone only familiar with more traditional build systems (autotools, make) might understand?
The includes are supposed to be added by this code in libs/python/build/Jamfile.v2: [ cond [ python.configured ] : <library>/python//python_for_extensions ] where 'cond' is basically C's ?: operator. From your log, I suspect that python.configured is not set, because python.jam is unable to run python to check it's version. Could you try the below patch? - Volodya diff --git a/tools/python.jam b/tools/python.jam index 66f2aab..0c41221 100644 --- a/tools/python.jam +++ b/tools/python.jam @@ -816,6 +816,10 @@ local rule configure ( version ? : cmd-or-prefix ? : includes * : libraries ? : version ?= 2.5 ; exec-prefix ?= $(prefix) ; compute-default-paths $(target-os) : $(version) : $(prefix:E=) ; + if $(includes) && $(libraries) + { + .configured = true ; + } } if ! $(interpreter-cmd)
participants (3)
-
Ben Gamari -
Dave Abrahams -
Vladimir Prus