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

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-25 10:30:05

Patrik Jonsson <patrik_at_[hidden]> writes:

>>
> 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