Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-05 14:38:04


This is mostly for Rene, since it concerns his "stage" target rules... but
it's an interesting issue for builds in general.


I'm delivering Boost.Python on AIX among other platforms. is a shared library which gets used by a bunch of
dlopen'ed Python modules each of which gets loaded by Python.

The Hitch:

AIX has a screwy one-way dynamic linking model which means that can't see any symbols in the Python executable... at
least, not without intervention.

Martin Casado did the spadework to dig up the answer, by looking in the
Python source. You see, all Python extension modules also need to be able
to access symbols in the Python executable as well, so they suffer the same
constraint. If you look in Python/dynload_aix.c in your Python distro,
you'll see the code which handles this.

Rather than replicating all of this logic, we decided that the trick would
be to have import itself as an extension module, so that
Python would patch up all of the symbols for us
(libs/python/src/aix_init_module.cpp). That means has to
contain an extern "C" function called initlibboost_python() which calls its
own module initialization function. There are a few other places where it
needs to know its own name. Finally, since is now
technically an extension module, it needs -einitlibboost_python in its link
line to export the entry point.

OK, I think you can see where this is going: the default build of Boost now
uses the stage target to build and, not to mention which
could come up. Right now, stage causes targets to be relinked, but there's
no provision for causing them to be recompiled. It would be fine if there
was a way of controlling target name based on variant even for non-stage
library and executable targets... but we don't have that.

So, I think the AIX release of Boost.Python is going to be incomplete in
this way... unless there's an obvious way out.


David Abrahams * Boost Consulting
dave_at_[hidden] *


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at