Bob Ippolito wrote:
> The bz2 module is part of the Python distribution. The best route
> would be to download the Python source, extract the source for the
> bz2 extension and create a standalone setup.py for it. Tweak it such
> that it links to a copy of libbz2 that you've compiled statically and
> universally, and then replace your Python installation's bz2 with
> that one.
>> It's not really trivial, but it's the only option you have unless
> someone else does it first. It sounds like Ronald will probably
> create another 2.4.3 installer in the future that fixes this and a
> few other issues, but I don't know when he'll get around to it (if
> ever, I don't speak for his free time).
>> In your situation, I would just give up on 10.3 users until the issue
> with Python is resolved (which is either going to happen when 2.5
> comes out, or when the 2.4.3 installer gets updated).
A last question to help me understand things.
At http://undefined.org/python/py2app.html, I read that, among other
things, py2app will "Make the application bundle standalone" like this:
"""
o Since a typical Python application may have C library dependencies,
such as the Python interpreter itself, wxWidgets, etc. a second
dependency resolution pass occurs on the application bundle.
o Scan the application bundle for all Mach-O files (executables, shared
libraries, plugins, extensions, etc.).
o Read the load commands from every Mach-O file (using macholib) and
build a dependency graph.
o Copy in every dependent dylib (shared library) and framework that is
not already in the application bundle. Note that dylibs and frameworks
in vendor locations (/System and /usr - except for /usr/local) are NOT
included in your application bundle. This can include the Python
interpreter, if you are using a Python interpreter shipped with Mac OS
X. Thus your application may be "tightly bound" to a particular major
version of Mac OS X if you are using the vendor Python.
o Rewrite the Mach-O load commands such that the libraries know that
they have moved inside of an application bundle (i.e. using
@executable_path relative ids).
o Strip every Mach-O file of extraneous information (debugging symbols,
etc.) to save space. This may be disabled with --no-strip.
"""
My particular question is about the "Copy in every dependent dylib..."
and "Rewrite the Mach-O load commands such that the libraries know that
they have moved inside of an application bundle..." steps. Why do these
steps not apply in the case of the bz2 library that I'm having trouble with?
Mike