David Abrahams wrote:
I don't think so; those were only a selection of the messages, not meant to be a complete dump.
It seems clear to me that the command used to do the compilation,
g++ ...whatever...
is generating XCOFF32 object files, either because the g++ in the path is the wrong one, or because we ought to be passing some special flag to make it generate 64-bit object files.
Yes. That flag is "-maix64", and it works.
I don't see any architecture called "IBM SP2," as Patrik said he was targeting, at http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/, but I guess that -maix64 must be supported despite not being documented (Patrik, you should report that as a GCC bug!)
No, it's in there. The architecture is "PowerPC and RS/6000".
Patrik, in order to address this, we (and thus you) will have to know what the proper compiler options are for targeting your platform. I suggest you pass "-odump.txt" as the first argument to bjam and look at the resulting "dump.txt" file to make sure the command-lines look
Thanks for the -o option, that made things easier to debug. I think I've got it mostly working now (with gcc 3.4, with 3.2 it fails with strange pthread errors), using the command bjam -a "-sTOOLS=gcc" "-sBUILD=<cxxflags>-maix64 <linkflags>-maix64 <arflags>-X 64" --prefix=$HOME --libdir=$HOME/lib64-gcc --includedir=$HOME/include-gcc install This seems to build most of the shared libraries, but some things won't build under 64-bit (see below). However, the <arflags> doesn't work. The resulting ar command looks something like "/usr/bin/ar" ru-X "bin/boost/libs/filesystem/build/libboost_filesystem.a/ gcc/64/libboost_filesystem-gcc-1_32.a" "bin/boost/libs/filesystem/build/libboos t_filesystem.a/gcc/64/exception.o" "bin/boost/libs/filesystem/build/libboost_fil esystem.a/gcc/64/operations_posix_windows.o" "bin/boost/libs/filesystem/build/li bboost_filesystem.a/gcc/64/path_posix_windows.o" "bin/boost/libs/filesystem/buil d/libboost_filesystem.a/gcc/64/convenience.o" The correct command line to get ar to process 64-bit files is "ar -X 64 ru ...". The -X option is put in the wrong place, and the 64 ended up completely wrong. I don't know how to specify this. One solution would be to replace "ar" with "ar -X 64", which I tried to do (on a hunch> with "<ar>ar -X 64" but that did no good either. Perhaps someone could tell me how to do this? Now, about the compiler errors: When compiling the python library, I'm getting gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o In file included from /usr/common/usg/python/2.3.2/include/python2.3/Python.h:48, from /scratch/scratchdirs/patrik/boost_1_32_0/boost/python/detail/wrap_python.hpp:121, from /scratch/scratchdirs/patrik/boost_1_32_0/boost/python/detail/prefix.hpp:13, from /scratch/scratchdirs/patrik/boost_1_32_0/boost/python/numeric.hpp:8, from /scratch/scratchdirs/patrik/boost_1_32_0/libs/python/build/../src/numeric.cpp:6: /usr/common/usg/python/2.3.2/include/python2.3/pyport.h:554:2: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." set -e "g++" -c -Wall -ftemplate-depth-255 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -fno-inline -fPIC -maix64 -I"bin/boost/libs/python/build" -I "/usr/common/usg/python/2.3.2/include/python2.3" -I "/scratch/scratchdirs/patrik/boost_1_32_0" -o "bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o" "/scratch/scratchdirs/patrik/boost_1_32_0/libs/python/build/../src/numeric.cpp" ...failed gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o... gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/list.o In file included from /usr/common/usg/python/2.3.2/include/python2.3/Python.h:48, from /scratch/scratchdirs/patrik/boost_1_32_0/boost/python/detail/wrap_python.hpp:121, from /scratch/scratchdirs/patrik/boost_1_32_0/boost/python/detail/prefix.hpp:13, from /scratch/scratchdirs/patrik/boost_1_32_0/boost/python/list.hpp:8, from /scratch/scratchdirs/patrik/boost_1_32_0/libs/python/build/../src/list.cpp:5: /usr/common/usg/python/2.3.2/include/python2.3/pyport.h:554:2: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." Could this be because the 64-bit option has changed the lengths of some types? I don't know what LONG_BIT does, but it's 32 in 32-bit mode and 64 in 64-bit mode. sizeof(long) is 8, but SIZEOF_LONG=4 in pyconfig.h. Maybe this is all because python was compiled as 32-bit and that means the python interface stuff won't work under 64-bit? Anyway, if that's the only thing that doesn't work, I'll be happy... In general, it seems it would make sense to have dedicated functionality to switch between 32 and 64-bit ABI on machines where this makes sense, especially since I guess this now affects AMD Athlon64 machines and not just us fringe RS/6000 users... ;-) /Patrik