[Pythonmac-SIG] Why do I need PantherPythonFix?

[Bob Ippolito]

On Feb 21, 2005, at 4:16 AM, Roger Binns wrote:

>> They are NOT AT ALL designed to be able to facilitate writing 
>> software that  links against a previous version.
>
> With BitPim on Windows and Linux, the Python interpretter is 
> distributed
> as part of the binary package.  There is absolutely no dependencies on
> what the user's system has, except base C and X libraries.
>
> The build machine uses the standard Python and wxPython binary 
> distributions
> for the relevant platform, which means that the same binaries as are 
> used
> by thousands of other users are used.
>
> Consequently there is a very high confidence in the binary distributed 
> app.
>
> I can also have multiple versions of Python installed on developer 
> machines.
> Extensions have to be compiled against each version and are installed 
> in
> the corresponding site-packages directory.  I've never tried moving 
> the Pythons after installation and have no idea if it would work or 
> not,
> and don't care if it doesn't.

Did you read and understand the versioned frameworks blog entry I 
linked to?  What you're saying has basically no relevance to what I 
said.

>> However, it's common to have Python  2.3 and Python 2.4 installed and 
>> want to be able to link new software  against 2.3, so the default 
>> framework mechanisms are not suitable for  this.
>
> If you use distutils on other platforms, it uses the directory it
> corresponds to.  For hand built stuff, you can do something similar:
>
> INCLUDEDIR=`python -c "import distutils.sysconfig; print 
> distutils.sysconfig.get_python_inc()"`
>
> I am still baffled as to what problem is being solved.  Are you
> trying to allow extensions built against Python 2.3 to magically
> work on 2.4.  (That isn't even possible under Windows and unlikely
> on Linux).

The includes directory has never been the problem.  This issue is only 
related to the linker, not the compiler.

Under certain circumstances, prior to Python 2.3.5/2.4.1, then 
extensions built on 2.3 would magically work for neither Python 2.3 or 
2.4 because they were linked against the 2.4 dylib with 2.3 headers, so 
you'd get an API mismatch (which is a warning not a hard error, but 
still..).

No.  The "-framework Python" link command was originally being used.  
It had the following problems:
(a) in Python 2.3.0-ish times, it was used without "-F".  That meant 
the newest version Python in ~/Library/Frameworks or 
/Library/Frameworks would be preferred regardless of which Python you 
were using.
(b) in Python 2.3.1-ish times(?) it was used with "-F".  That means 
that you were guaranteed to get the right Frameworks directory in play, 
but it would still link to the newest version of Python regardless of 
which one you are using.
(c) in Python 2.3.5 it links to the Python dylib directly, not 
utilizing any of GCC's search algorithms, and now does the right thing 
all the time.

Even with this, due to the way Mach-O works, it breaks an invariant 
that you have on other platforms:  It's possible to share extensions 
between Pythons of the same major version (e.g. 2.3.x), regardless of 
where these Pythons are installed.  When Python is built to target Mac 
OS X 10.3 or later using the "-undefined dynamic_lookup" linker flag, 
when using PantherPythonFix on 2.3.0, Python 2.3.5, or Python 2.4.x, 
then extensions are not even linked to the Python interpreter so this 
problem goes away and the invariant is preserved.

I understand your frustration in trying to understand the issues at 
hand here, but please know that they are tricky but solved.  This topic 
comes up a lot and I'm pretty tired of talking about it.

> It also looks like py2app doesn't include the Python interpretter.
> Is that the case?  Is that the cause of all these issues?  Is
> there any reason not to include the Python interpretter?  From
> a software quality standpoint, I definitely want the exact Python
> interpretter from the build machine to be redistributed along
> with the binary app.

from <http://undefined.org/python/py2app.html>

   - Make the application bundle standalone

     - 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.
     - Scan the application bundle for all Mach-O files (executables, 
shared libraries,
       plugins, extensions, etc.).
     - Read the load commands from every Mach-O file (using 
**macholib**) and build
       a dependency graph.
     - 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.
     - 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).
     - Strip every Mach-O file of extraneous information (debugging 
symbols, etc.)
       to save space.  This may be disabled with ``--no-strip``.

-bob