Re: [Boost-users] Re: Building boost for 64-bit on AIX

From: Patrik Jonsson (patrik_at_[hidden])
Date: 2005-05-25 00:34:27

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