[C++-sig] MacOSX building... of shared libraries...

[Rene Rivera]

[2002-10-28] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> OK... more results and observations...
>> 
>> Using libpython2.2.a does help! After making more changes, to build
dylibs
>> instead of bundles. Which requires a fun trick I've used before of double
>> linking, in this case to resolve common symbols defined in libpython. I
>> managed to get the minimal _ext to link correctly :-)
>
>Wow, it sounds like you are getting really close!

So close, yet so far :-(

>Ideas:
>
>- Describe your remaining problem to Jack Janssen
(http://www.cwi.nl/~jack/).
>He is maintaining the Python Apple port. He must have had similar problems
when
>porting the standard Python "C" extension modules (e.g. all the files in
>/usr/local_cci/Python-2.2.2t/lib/python2.2/lib-dynload).

I looked at some of his documentation, and some of the code, and tried a few
things out.

>- Run the Python installation to see how the standard modules are built.

Did that... the Python installation fails to compile. It was rather funny,
it failed right at the last link because it was trying to link "python" but
there already existed a "Python" directory.


All in all I did manage to make more progress... After some thinking I came
up with this arragement:

    1. Build libboost_python as a dylib, shared library that is linked to
libpython*.a
    2. Build the extensions as a bundle, that load from the "python2.2"
executable.

That not only links, but also runs, that is it loads the module... almost!
This is when I ran into the last problem. Because libboost_python links to
libpython*.a and the extentions to python2.2(exe), the loader (MacOSX dyld)
barfs from duplicate symbol clashes. All kinds of Python(_Py*) symbols that
are defined in both the executable and the library. The reason... python2.2
is not normally linked to the common library, and that is an insurmountable
arrangement. So this approach is failure :-( --- for now...

But there is an ultimate solution to the problem... Boost.Python will have
to wait for Python2.3. With it one should be able to have the commandline
python built as a MacOSX Framework (fancy term for shared library). That way
everybody links to the framework and no more duplicate symbols. Hooray.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org