Re: [jamboost] Fun with dynamic linking on AIX

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-10-05 18:05:41

[2002-10-05] David Abrahams wrote:

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

>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.

It took me a while to figure out why that paragraph is important. But after
reading the aix_init_module.cpp file I understood.

>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.

But we could have that... with some small effort... after all the <tag> code
is isolated and could be used in declare-local-target. But the problem that
raises is that renaming targets make it all the more entertaining, that is
hard, to refer to them from other places, like the test framework and stage
itself.

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

I think there's an obvious way out... What I think you're after is a way of
changing the currently hardwired name of the library depending on the build
your doing. That's what having toolset and/or variant selectable
requirements where designed for ;-) Here's the suggestion, add a define that
specifies the name of the target library file to the requirements of "dll
boot_python", like so:

<release><define>BOOST_PYTHON_NAME=\\\"libboost_python.so\\\\"
<debug><define>BOOST_PYTHON_NAME=\\\"libboost_python_debug.so\\\\"
<python-debug><define>BOOST_PYTHON_NAME=\\\"libboost_python_pydebug.so\\\\"

And then in your code use the BOOST_PYTHON_NAME instead of the literal
string.

The only problem with this is that then using the boos_python target from
other places, like the test targets, will set the name incorrectly because
in those circumstances it needs the direct name ("libboost_python.so").

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]