MacOSX building... of shared libraries...

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-10-27 23:00:09

I've been working on the "darwin-tools.jam" toolset to try and get Boost &
Boost.Python working on MacoOSX. (Thanks to Ralf for access to the MacOSX
machine :-)

...And here are some conclusions...

The toolset is minimally working for standard compilation. But the
compilation of shared libraries is limited at best. That is the toolset is
working to generate both "dylib" and "bundle" type shared libraries. The
problem is... that this doesn't work for Boost.Python in it's current form.

After much reading and many different attempts I've learned some things
about MacOSX.

1. "dylib" shared libraries are what I would consider standard shared
libraries in the Unix sense.
2. "bundle" shared libraries are what Apple thinks application plugins
should be like.

That's all nice, but the way Apple changed the compiler, linker, and loader
to implement that makes the above arrangement problematic for code like
Boost.Python. The problems are:

a. "dylib" shared libraries don't seem to support resolving of symbols back
from the application loading the library. Like the AIX loading problem.

...not a problem, after all that's what "bundles" are for, right? but...

b. "bundle" shared libraries do resolve the symbols from the loader context
as long as you specify the loader binary when linking, using the
-bundle_loader flag. And the current build system files in CVS do this when
using the darwin toolset. But bundles have one limitation, they can't depend
on other bundles. So if I build boost_python as a bundle, other python
extensions can't use it as a dependence as one would in Linux.

So I have two options, neither of which work for Boost.Python. So if anyone
has suggestions or insights I would welcome them ;-\

Or for that matter.. is there any way to rearrange the Boost.Python code so
that is doesn't need to link against the python executable? Which would turn
it into what Apple calls a framework, to break the inter-dependence problem.

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