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