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.
libboost_python.so is a shared library which gets used by a bunch of
dlopen'ed Python modules each of which gets loaded by Python.
AIX has a screwy one-way dynamic linking model which means that
libboost_python.so 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 libboost_python.so 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 libboost_python.so 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 libboost_python.so 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 libboost_python.so and
libboost_python_debug.so, not to mention libboost_python_pydebug.so 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] * http://www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk