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@acm.org - grafik@redshift-software.com -- 102708583@icq - Grafik666@AIM - Grafik@jabber.org
--- Rene Rivera <grafik666@redshift-software.com> wrote:
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.
Did you consider linking against libpython2.2.a ? I just checked, this file is missing in the /usr/lib/python2.2/config directory supplied by Apple. However, there is now a Python 2.2.2 installation in /usr/local_cci/Python-2.2.2t (t = threaded) with a file /usr/local_cci/Python-2.2.2t/lib/python2.2/config/libpython2.2.a . Ralf __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
--- Rene Rivera <grafik666@redshift-software.com> wrote:
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
[2002-10-27] Ralf W. Grosse-Kunstleve wrote: problem.
Did you consider linking against libpython2.2.a ? I just checked, this file
is
missing in the /usr/lib/python2.2/config directory supplied by Apple. However, there is now a Python 2.2.2 installation in /usr/local_cci/Python-2.2.2t (t = threaded) with a file /usr/local_cci/Python-2.2.2t/lib/python2.2/config/libpython2.2.a .
No, and yes... I looked for such a thing but didn't find it. Thanks for pointing it out I'll try that and see if it makes things easier. -- grafik - Don't Assume Anything -- rrivera@acm.org - grafik@redshift-software.com -- 102708583@icq - Grafik666@AIM - Grafik@jabber.org
--- Rene Rivera <grafik666@redshift-software.com> wrote:
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
[2002-10-27] Ralf W. Grosse-Kunstleve wrote: problem.
Did you consider linking against libpython2.2.a ? I just checked, this file
is
missing in the /usr/lib/python2.2/config directory supplied by Apple. However, there is now a Python 2.2.2 installation in /usr/local_cci/Python-2.2.2t (t = threaded) with a file /usr/local_cci/Python-2.2.2t/lib/python2.2/config/libpython2.2.a .
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 :-) ...Now the revelations, and more problems... Python wants *.so files instead of *.dylib files, I'm talking names not type here. Not a problem after all it's just a name. So I rename the file and try again and boom Python complains with: "ImportError: Inappropriate file type for dynamic loading" Which means that Python can, so far, only load MacOSX "bundles". So even though the libpython helps me create dynamic libs that correctly reference each other and Python. One can't load them anyway :-( So this problem goes back to Apple... How does one create bundles that can refer to other bundles? If it's even possible! -- grafik - Don't Assume Anything -- rrivera@acm.org - grafik@redshift-software.com -- 102708583@icq - Grafik666@AIM - Grafik@jabber.org
--- Rene Rivera <grafik666@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!
...Now the revelations, and more problems...
Python wants *.so files instead of *.dylib files, I'm talking names not type here. Not a problem after all it's just a name. So I rename the file and try again and boom Python complains with:
"ImportError: Inappropriate file type for dynamic loading"
Which means that Python can, so far, only load MacOSX "bundles". So even though the libpython helps me create dynamic libs that correctly reference each other and Python. One can't load them anyway :-(
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). - Run the Python installation to see how the standard modules are built. - This is a wild one: make a "thin bundle" that dispatches to the dynamic libs that you have already. Ralf __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
[2002-10-28] Ralf W. Grosse-Kunstleve wrote:
--- Rene Rivera <grafik666@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@acm.org - grafik@redshift-software.com -- 102708583@icq - Grafik666@AIM - Grafik@jabber.org
Rene Rivera <grafik666@redshift-software.com> writes:
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...
Rene, Thanks for pursuing this. I've forwarded your message to my contact on the Apple compiler team. Maybe it will lead somewhere... -Dave -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com
participants (3)
-
David Abrahams -
Ralf W. Grosse-Kunstleve -
Rene Rivera