Patrik Jonsson
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"
Hm. Rene, this one's your line: 1.87 (grafik 05-Mar-04): "$(.AR[1])" ru$(ARFLAGS:J=) "$(<)" "$(>)" Do you know what's going on?
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.
Actually I think you need to do <arflags>-X <arflags>64 if you want it to work.
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?
Could be, but normally this is because we've semehow failed to #include Python.h header before the standard header that defines LONG_BIT.
I don't know what LONG_BIT does, but it's 32 in 32-bit mode and 64 in 64-bit mode.
Tells you how many bits are in a long.
sizeof(long) is 8, but SIZEOF_LONG=4 in pyconfig.h.
Ah, that looks like your problem right there.
Maybe this is all because python was compiled as 32-bit and that means the python interface stuff won't work under 64-bit?
Sounds like it.
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... ;-)
Well, we do have <address-model>64 -- Dave Abrahams Boost Consulting www.boost-consulting.com