Le dimanche 5 octobre 2008, Kim Barrett a écrit :
At 2:22 PM +0200 10/3/08, raoul wrote:
I googled a bit, and it seems that this problem is because libboost_python was not compiled with the same python version than the one I've corsscompiled with.
And this is the problem. When reading the boost compilation log: "i686-unknown-linux-gnu-gcc" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG -I"." -I"/usr/include/python2.5" -c -o "bin.v2/libs/python/build/gcc-calaos/release/threading-multi/dict.o" "libs/python/src/dict.cpp"
bjam is using the host include path for python (the -I/usr/include/python2.5 option), and this is wrong. How can I force bjam to use ${ROOTFS_DIR}/usr/include/python2.5 for python include path, instead of the one of my host system?
http://www.boost.org/doc/libs/1_36_0/libs/python/doc/building.html Section 5.1 Python Configuration Parameters
For cross-compilation, what has worked for me is for the cmd-or-prefix to be the runtime prefix while includes and libraries point to the appropriate places in the cross-compile environment, which are typically completely different from the runtime prefix.
This is exactly what I was looking for. Adding: echo "using python : : ${ROOTFS_DIR}/usr/bin/python ;" >> tools/build/v2/user-config.jam to my build script and it works like charm... Thanks! -- ------------------------ Raoul Hecky