Using boost.python with make instead of bjam

I'm just trying to compile the "hello world" example of boost.python WITHOUT using all the bjam magic. My boost.python installation is working, I did succesfully build the example with bjam and passed the test suite.

Now for my project I need to use all this stuff in a plain Make environment. I don't want to port to another build tool.

So my naive approach is of course to just point the include path to the right headers and link against the right library. I built boost python as system-layout, static, runtime-static, which means it is just a libboost_python.a that resides in /usr/local/lib.

Unfortunately, I get unresolved external symbols in the resulting .so library.

Here is my try to build the example from libs/python/example/tutorial/hello.cpp:

$ cat hello.cpp
//  Copyright Joel de Guzman 2002-2004. Distributed under the Boost
//  Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt
//  or copy at http://www.boost.org/LICENSE_1_0.txt)
//  Hello World Example from the tutorial
//  [Joel de Guzman 10/9/2002]

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>

char const* greet()
{
   return "hello, world";
}

BOOST_PYTHON_MODULE(hello_ext)
{
    using namespace boost::python;
    def("greet", greet);
}

$ g++ -I/usr/local/include -I/usr/include/python -fpic -c -o hello.o
hello.cpp
$ g++ -shared -Wl,-soname,"libhello.so" -L/usr/local/lib -lboost_python -fpic -o libhello.so hello.o
$ nm -u libhello.so
                 U PyString_Type
                 w _Jv_RegisterClasses
                 U _Py_NoneStruct
                 U _Unwind_Resume@@GCC_3.0
                 U _ZN5boost6python6detail11init_moduleEPKcPFvvE
                 U _ZN5boost6python6detail12gcc_demangleEPKc
                 U
_ZN5boost6python6detail17scope_setattr_docEPKcRKNS0_3api6objectES3_
                 U
_ZN5boost6python7objects15function_objectERKNS1_11py_functionE
                 U _ZN5boost6python7objects21py_function_impl_baseD2Ev
                 U _ZN5boost6python9converter19do_return_to_pythonEPKc
                 U _ZN5boost6python9converter8registry5queryENS0_9type_infoE
                 U
_ZNK5boost6python7objects21py_function_impl_base9max_arityEv
                 U
_ZNK5boost6python9converter12registration25expected_from_python_typeEv
                 U _ZTIN5boost6python7objects21py_function_impl_baseE
                 U _ZTIPKc@@CXXABI_1.3
                 U _ZTIc@@CXXABI_1.3
                 U _ZTVN10__cxxabiv120__si_class_type_infoE@@CXXABI_1.3
                 U _ZTVN5boost6python7objects21py_function_impl_baseE
                 U _ZdlPv@@GLIBCXX_3.4
                 U _Znwm@@GLIBCXX_3.4
                 U __cxa_atexit@@GLIBC_2.2.5
                 w __cxa_finalize@@GLIBC_2.2.5
                 U __cxa_guard_abort@@CXXABI_1.3
                 U __cxa_guard_acquire@@CXXABI_1.3
                 U __cxa_guard_release@@CXXABI_1.3
                 w __gmon_start__
                 U __gxx_personality_v0@@CXXABI_1.3
$ python
>>> import libhello
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: ./libhello.so: undefined symbol:
_ZNK5boost6python7objects21py_function_impl_base9max_arityEv

So what is the big magic of bjam that when bjam links libboost_python.a I get no undefined symbols, but when i do it "by hand" i get these?

Well, I was obiously stupid. To link one has to put the object BEFORE the library with the symbols. So turning

g++ -shared -Wl,-soname,"libhello.so" -L/usr/local/lib -lboost_python -fpic -o libhello.so hello.o

into

g++ -shared -Wl,-soname,"libhello.so" -L/usr/local/lib hello.o -lboost_python -fpic -o libhello.so

Gave me the expected result, after I recompiled boost.python with cxxflags=-fPIC.