Boost logo

Boost :

Subject: Re: [boost] Packaging in cross-compiling environment
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-12-25 02:42:15

Ben Gamari wrote:

> 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-
> 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-
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
> "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

Boost list run by bdawes at, gregod at, cpdaniel at, john at