Linking static library into shared library?

[gct]

OK so I'm trying to get boost python working in a project I'm working on, the net result of my build should be a single python module. I'd like to avoid forcing my users to actually install boost to their system, so I'm just building it locally during the install and I want to statically link against it.

This is what I'm doing right now:

gcc -fPIC -c -O2  pd_pipe.cc -o pd_pipe.o
gcc -fPIC -O2 -shared ../lib/libboost_python-gcc41-mt.a *.o -o pydsp.so

Note that I've removed the -I's and -L's for clarity. At any rate, this compiles and links together just fine but when I try to load the module into a python, I get an error about a missing symbol. I tried swapping the order things are linked in and the error changed to a different symbol.

So it looks like as they're being linked together, later object files are overwriting symbols in earlier object files somehow...

Note that when I link against the shared boost library, things work just fine.

Does anyone know what I'm doing wrong here? How can I properly link a static library into a shared library?

[Zaita]

When you compile the boost libraries there are different options. By default I believe it compilers as a shared library. You need to compile it statically.

The name of the library will also then contain and 's' denoting that it's a static library.

e.g. libboost_thread-mgw34-mt-sd-1_35.lib
sd = Static-Debug

That was compiled for MingW GCC 3.4.5 and I have the same for GCC 4+ on Linux.

[gct]

Do you have more information on this? Looking at the configure script for boost 1.36, I see this, which doesn't have any information about static compilation. I didn't find anything in the online docs either..

`configure' configures Boost to adapt to a few kinds of systems.

Usage: ./configure [OPTION]...

Defaults for the options are specified in brackets.

Configuration:
-h, --help display this help and exit
--with-bjam=BJAM use existing Boost.Jam executable (bjam)
[automatically built]
--with-toolset=TOOLSET use specific Boost.Build toolset
[automatically detected]
--show-libraries show the set of libraries that require build
and installation steps (i.e., those libraries
that can be used with --with-libraries or
--without-libraries), then exit
--with-libraries=list build only a particular set of libraries,
describing using either a comma-separated list of
library names or "all"
[all]
--without-libraries=list build all libraries except the ones listed []
--with-icu enable Unicode/ICU support in Regex
[automatically detected]
--without-icu disable Unicode/ICU support in Regex
--with-icu=DIR specify the root of the ICU library installation
and enable Unicode/ICU support in Regex
[automatically detected]
--with-python=PYTHON specify the Python executable [python]
--with-python-root=DIR specify the root of the Python installation
[automatically detected]
--with-python-version=X.Y specify the Python version as X.Y
[automatically detected]

Installation directories:
--prefix=PREFIX install Boost into the given PREFIX
[/usr/local]
--exec-prefix=EPREFIX install Boost binaries into the given EPREFIX
[PREFIX]

More precise control over installation directories:
--libdir=DIR install libraries here [EPREFIX/lib]
--includedir=DIR install headers here [PREFIX/include]

[gct]

Edit: found this in the docs:

6 Choosing a Boost.Python Library Binary

If—instead of letting Boost.Build construct and link with the right libraries automatically—you choose to use a pre-built Boost.Python library, you'll need to think about which one to link with. The Boost.Python binary comes in both static and dynamic flavors. Take care to choose the right flavor for your application.2

Which would jive with the libraries that the make generated:

libboost_python-gcc41-mt-1_36.a
libboost_python-gcc41-mt.a
libboost_python-gcc41-mt-1_36.so
libboost_python-gcc41-mt.so
libboost_python-gcc41-mt-1_36.so.1.36.0

[Zaita]

./bjam --toolset=gcc --build-type=complete