[Boost-build] How to build static python-extension?

Subject: [Boost-build] How to build static python-extension?
From: Amos Anderson (amos.anderson_at_[hidden])
Date: 2014-09-30 21:05:18

Hi Boost Build --

I'm trying to figure out how to build a static python extension using boost 1.55. I have a setup which can compile shared libraries successfully, so now I'm trying to figure out how to modify my Jamroot/Jamfile to do static instead.

It's a large project, but here are the changes I've made. I added <link>static to my variant which is defined in my Jamroot:

variant release-myapp :
   <optimization>speed
   <debug-symbols>on
   <inlining>full
   <runtime-debugging>off
   <parallelism>mpi
   <link>static
;

and in the Jamfile with the python extensions, I have this:

python-extension myappCPP : 
    file1.cc
    file2.cc
    ...
    /otherproject1//project1
    /otherproject2//project2
    :
    <link>static
    ;

and for good measure, when I call bjam I add "-d 2 variant=release-myapp link=static" to the command line. It *looks* like everything is compiling as expected (i.e. the other projects are all resulting in .a files as expected). For example, when file1.cc gets compiled, I see:

gcc.compile.c++ pymodule/bin/gcc-4.1.2/release-myapp/threading-multi/file1.o

    "g++"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -g -pthread -ftemplate-depth-256 -Dmyapp_MPI -Dkiss_fft_scalar=double -Wno-unknown-pragmas -Wstrict-aliasing=2 -fno-strict-aliasing -DBOOST_PYTHON_MAX_ARITY=30 -DBOOST_PYTHON_STATIC_LIB -DBOOST_SYSTEM_STATIC_LINK=1  -I"../tools/boost" -I"../tools/python/include/python2.7" -I"/home/user/myapp3/tools/openmpi/include" -c -o "pymodule/bin/gcc-4.1.2/release-myapp/threading-multi/file1.o" "pymodule/file1.cc"

which appears to be correct. Other non-python projects appear to be producing static libraries as expected. However, when it tries to build the python extension library, it looks like it's trying to build a shared library:

gcc.link.dll pymodule/bin/gcc-4.1.2/release-myapp/threading-multi/myappCPP.so

    "g++" -L"/home/user/myapp3/tools/apbs/lib" -L"/home/user/myapp3/tools/hdf5/lib" -L"/home/user/myapp3/tools/kdl/lib" -L"/home/user/myapp3/tools/openmpi/lib"   -o "pymodule/bin/gcc-4.1.2/release-myapp/threading-multi/myappCPP.so" -Wl,-h -Wl,myappCPP.so -shared -Wl,--start-group "pymodule/bin/gcc-4.1.2/release-myapp/threading-multi/file1.o" <snip>   -Wl,-Bstatic -lorocos-kdl -lapbs_pmgc -lapbs_mg -lapbs_generic -lmaloc -lhdf5_cpp -lhdf5 -lutil -lpthread -ldl -Wl,-Bdynamic -ldl -lm -lmpi -lmpi_cxx -lnsl -lrt -lutil -lutil -lpthread -ldl -lrt -Wl,--end-group -g -pthread -Wl,--export-dynamic

/usr/bin/ld: pymodule/bin/gcc-4.1.2/release-myapp/threading-multi/file1.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
pymodule/bin/gcc-4.1.2/release-myapp/threading-multi/file1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

where that last g++ line has quite a bit of text that has been snipped out (i.e. all the other object files). I can't find any other places where a "static" tag would be effective. Is there something I'm doing wrong?

Thanks!
Amos.

p.s. if it matters, I tried runtime-link=static too, but when that compiled it also tried to build a file called myappCPP.so, also used the -shared flag, but which failed with a different link error:

    "g++" -L"/home/user/myapp3/tools/apbs/lib" -L"/home/user/myapp3/tools/hdf5/lib" -L"/home/user/myapp3/tools/kdl/lib" -L"/home/user/myapp3/tools/openmpi/lib"   -o "pymodule/bin/gcc-4.1.2/release-myapp/runtime-link-static/threading-multi/myappCPP.so" -Wl,-h -Wl,myappCPP.so -shared -Wl,--start-group "pymodule/bin/gcc-4.1.2/release-myapp/runtime-link-static/threading-multi/OneD_BP.o" <snip>   -lorocos-kdl -lapbs_pmgc -lapbs_mg -lapbs_generic -lmaloc -lhdf5_cpp -lhdf5 -lutil -lpthread -ldl  -ldl -lm -lmpi -lmpi_cxx -lnsl -lrt -lutil -lutil -lpthread -ldl -lrt -Wl,--end-group -g -static -pthread -Wl,--export-dynamic

/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginT.o: could not read symbols: Bad value