Cross compiling boost for Embedded Planet ppc_82xx question
I'm trying to cross-compile boost for the Embedded Planet PowerPC 82xx target platform and have a few questions. This is the first time I've used jam so I'm a bit disoriented. Can somebody help? The build platform is a vanilla Redhat 9 system for which the target processor vendor provides a cross-compiler (ppc_82xx_gcc). This is a modified version of gcc that builds applications to run under their Linux kernel/application environment, supplied as a collection of rpm images. These are installed on the host file system and exported to the target platform via NFS. All this is in place now and apparently is working, at least insofar as having compiled ACE/TAO successfully (as yet untested). Question is, how do I compile boost for this platform? I've copied tools/build/v1/gcc-tools.jam to tools/build/v1/ppc_82xx-tools.jam and changed the GCC/GXX settings in that file to ppc_82xx-gcc and ppc_82xx-g++ respectively, which is all that should be needed insofar as their compiler is concerned. Here's what I'm getting: jam needs to be told the target architecture somehow. Question is, how do I do this? /usr/local/tena-tools/i686-pc-linux-gnu/bin/bjam --prefix="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d" --builddir="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build" -sTOOLS="ppc_82xx-gcc" -sBUILD="debug <runtime-link>dynamic <threading>multi" -sGXX="ppc_82xx-gcc" -sGCC="ppc_82xx-gcc" install/usr/local/tena-tools/i686-pc-linux-gnu/bin/bjam --prefix="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d" --builddir="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build" -sTOOLS="ppc_82xx-gcc" -sBUILD="debug <runtime-link>dynamic <threading>multi" -sGXX="ppc_82xx-gcc" -sGCC="ppc_82xx-gcc" install/usr/local/tena-tools/i686-pc-linux-gnu/bin/bjam --prefix="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d" --builddir="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build" -sTOOLS="ppc_82xx-gcc" -sBUILD="debug <runtime-link>dynamic <threading>multi" -sGXX="ppc_82xx-gcc" -sGCC="ppc_82xx-gcc" install ...found 8259 targets... ...updating 226 targets... MkDir1 /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi gcc-C++-action /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/numeric.o /usr/bin/objcopy: Warning: Output file cannot represent architecture UNKNOWN! gcc-C++-action /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/list.o /usr/bin/objcopy: Warning: Output file cannot represent architecture UNKNOWN!
Brad Cox wrote:
I'm trying to cross-compile boost for the Embedded Planet PowerPC 82xx target platform and have a few questions. This is the first time I've used jam so I'm a bit disoriented. Can somebody help?
Yes... There's even a whole list dedicated to this, Jamboost, see... http://boost.org/more/mailing_lists.htm#projects [...]
Question is, how do I compile boost for this platform? I've copied tools/build/v1/gcc-tools.jam to tools/build/v1/ppc_82xx-tools.jam and changed the GCC/GXX settings in that file to ppc_82xx-gcc and ppc_82xx-g++ respectively, which is all that should be needed insofar as their compiler is concerned.
You should have been able to do that without changing the gcc-tools.jam, with -sGCC=ppc_82xx-gcc for example. But it looks like you're going to need to make more changes so it's actually good that you made a new toolset file.
Here's what I'm getting: jam needs to be told the target architecture somehow. Question is, how do I do this?
/usr/local/tena-tools/i686-pc-linux-gnu/bin/bjam --prefix="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d" --builddir="/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build" -sTOOLS="ppc_82xx-gcc" -sBUILD="debug <runtime-link>dynamic <threading>multi" -sGXX="ppc_82xx-gcc" -sGCC="ppc_82xx-gcc" install [...strange multi-copy of the same command] ...found 8259 targets... ...updating 226 targets... [...] /usr/bin/objcopy: Warning: Output file cannot represent architecture UNKNOWN!
That looks like the only problem you have. The use of the binutils/objcopy program is an optimization when building release versions. It reduces the symbols in the the object file to get around an inefficient N^2 algorithm in the linker. You have two choices.. 1. Remove the use of objcopy by removing the line this line in the toolset: flags gcc .OBJCOPY : [ GLOB $(GCC_BIN_DIRECTORY) $(PATH) : objcopy ] ; 2. Try and make the use of objcopy work, assuming you have one for the cross compile target. If there is one it would be part of the binutils build for the target so it's likely to be wherever the cross-linker is. If you find it, just add that directory to your PATH when building. For example (must be before the rest of PATH so it finds it first): bjam ... -sPATH=/some/dir/with/objcopy/bin:${PATH} ... Or changing the same above line to hardwire the location of the objcopy you want to use. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Brad Cox wrote: Yes... There's even a whole list dedicated to this, Jamboost, see... http://boost.org/more/mailing_lists.htm#projects
Thanks! Actually I subscribed there too. Should I move followup questions there?
1. Remove the use of objcopy by removing the line this line in the toolset:
flags gcc .OBJCOPY : [ GLOB $(GCC_BIN_DIRECTORY) $(PATH) : objcopy ] ;
Thanks! Changing objcopy in this line to ppc_82xx-objcopy nailed it. Much further along now; 261 lines in the log before the build derailed on python: /python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/object_operators.o gcc-Link-action /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/libboost_python-gcc-mt-d-1_31.so /data1/embedded/tools/usr/bin/../lib/gcc-lib/ppc-linux/3.2.2/../../../../ppc-linux/bin/ld: /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/numeric.o: Relocations in generic ELF (EM: 0) /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/numeric.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status Chmod1 /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/libboost_python-gcc-mt-d-1_31.so chmod: failed to get attributes of `/usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/libboost_python-gcc-mt-d-1_31.so': No such file or directory If I'm reading this right, looks like python is the only problem. Can I just ignore this? We're only using boost threads AFAIK. I'd rather do it completely though. BTW: I have a ppc_82xx-ld. Should I use that instead of the ppc-linux/bin/ld? Somehow? Looks like I'm close... ...failed updating 2 targets... ...skipped 2 targets... ...updated 218 targets... ~
Brad Cox wrote:
Rene Rivera wrote:
Brad Cox wrote: Yes... There's even a whole list dedicated to this, Jamboost, see... http://boost.org/more/mailing_lists.htm#projects
Thanks! Actually I subscribed there too. Should I move followup questions there?
Probably.. I'll start with this one :-)
1. Remove the use of objcopy by removing the line this line in the toolset:
flags gcc .OBJCOPY : [ GLOB $(GCC_BIN_DIRECTORY) $(PATH) : objcopy ] ;
Thanks! Changing objcopy in this line to ppc_82xx-objcopy nailed it.
Awesome.. like in Star Trek (tm) going for that third option :-)
Much further along now; 261 lines in the log before the build derailed on python:
/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/object_operators.o
gcc-Link-action /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/libboost_python-gcc-mt-d-1_31.so
/data1/embedded/tools/usr/bin/../lib/gcc-lib/ppc-linux/3.2.2/../../../../ppc-linux/bin/ld: /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/numeric.o: Relocations in generic ELF (EM: 0) /usr/local/boost/1.31.0/rh9-gcc322-ppc82xx-d/build/bin/boost/libs/python/build/libboost_python.so/ppc_82xx-gcc/debug/shared-linkable-true/threading-multi/numeric.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status
Now that's a strange error :-\
If I'm reading this right, looks like python is the only problem. Can I just ignore this? We're only using boost threads AFAIK. I'd rather do it completely though.
I'm not sure it's a Boost.Python problem...
BTW: I have a ppc_82xx-ld. Should I use that instead of the ppc-linux/bin/ld? Somehow?
Definitely! That's likely the above problem.. Using one linker with the output of a different compiler. But I'm not sure how you *are* managing to not use the ppc_82xx-ld linker. When one builds GCC for cross compile the linker is "hard coded" into the build so that it invokes only that when linking. And for bjam we just call GCC to do the linking not LD directly. Hmm... although there are other commands we do call directly... Specifically "ranlib" and "ar". For "ar" it finds it the same way as the objcopy (the line for that is above the objcopy lines). As for ranlib you can specify which one to use either by making sure it's first in the PATH. Or by specifying it in the bjam invocation: bjam .. -sRANLIB=/foo/bar/bin/ranlib .. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Thanks! Looks like adding -sRANLIB and -sAR definitions on the command line nailed it. There were a couple of errors on two damaged .o files from earlier builds. Removed those, rebuilt, and all was golden. One last question and I'll be outa here. What is the jam equivalent of "make clean?". Rene Rivera wrote:
BTW: I have a ppc_82xx-ld. Should I use that instead of the ppc-linux/bin/ld? Somehow?
Definitely! That's likely the above problem.. Using one linker with the output of a different compiler. But I'm not sure how you *are* managing to not use the ppc_82xx-ld linker. When one builds GCC for cross compile the linker is "hard coded" into the build so that it invokes only that when linking. And for bjam we just call GCC to do the linking not LD directly.
Hmm... although there are other commands we do call directly... Specifically "ranlib" and "ar". For "ar" it finds it the same way as the objcopy (the line for that is above the objcopy lines). As for ranlib you can specify which one to use either by making sure it's first in the PATH. Or by specifying it in the bjam invocation: bjam .. -sRANLIB=/foo/bar/bin/ranlib ..
Brad Cox wrote:
Thanks! Looks like adding -sRANLIB and -sAR definitions on the command line nailed it.
There were a couple of errors on two damaged .o files from earlier builds. Removed those, rebuilt, and all was golden.
One last question and I'll be outa here. What is the jam equivalent of "make clean?".
bjam clean Of course ;-) Although it doesn't behave the same as the usual make equivalent... It only removes the targets (.o, .lib, etc) it knows about. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (2)
-
Brad Cox -
Rene Rivera