[Python-Dev] OS X Installer for 3.0.1 and supported versions (original) (raw)

Ronald Oussoren ronaldoussoren at mac.com
Sun Feb 15 09:34:49 CET 2009

On 14 Feb, 2009, at 20:15, Martin v. Löwis wrote:

Ronald Oussoren wrote:

On 14 Feb, 2009, at 19:04, Martin v. Löwis wrote:

A single installer could support both 32-bit on 10.4 and 64-bit on 10.5, but I don't think that's very useful because there are changes in the low-level unix API's that could result in different behaviour of a 32-bit and 64-bit script on the same system. In general 10.5 has much saner Unix API's than earlier releases. I don't get that. Why would the scripts behave differently on 10.5 depending on whether the Python interpreter is 32-bit or 64-bit? Surely, the Unix API does the same thing, whether invoked from 32- bit code, or 64-bit code, no? I should have been more clear: the unix API for code that runs on 10.4 is slightly different than that for code that runs on 10.5+, Apple basiclly fixed a number of UNIX API-compliance issues in 10.5. So how come? Are you really saying that 10.5 somehow knows whether the code might also run on 10.4, and if so, deliberately behaves differently?

Yes. OSX supports a variant of symbol versioning. The dynamic linker
can see for which system a binary was compiler build and links the
right version of a symbol at runtime.

There's the comment in the header files that defines the macro's used
for symbol versioning:

/*

Simply put: when a binary is compiled to run on 32-bit 10.4 or earlier
it will be linked to pre-Unix03 symbols, otherwise it will be linked
with the Unix'03 compliant symbols/APIs. Some API's just behave
differently, others have a different signature as well.

So that a Python interpreter compiled for 10.4+ would behave differently on a specific 10.5 installation than a Python interpreter compiled for 10.5+, on the very same system? If so, I'm -1 on providing two sets of binaries for the same Python version (one in 10.4+ mode and one in 10.5+ mode). Otherwise, this sounds like a good source of confusion: "are you using Python 3.1 as compiled for 10.4 or 3.1 as compiled for 10.5?" - "well, how do I tell?"

It should be easy to provide that information.

And anyway, we already have confusion about python builds anyway: the
python.org, macports and fink builds of python are slightly different
and some issues seem to crop up with some of the builds more often
than with others. That is, I sometimes see questions on the pythonmac- sig from macports and fink users about issues that I've never run into
with the python.org build.

Is this Apple's DLL hell?

Not quite a hell, but still inconvenient. I guess it is time to start
digging to check which API's have a different definition in UNIX03 to
check if those could affect the behaviour of the Python interpreter.
I know the value of "GETPGRP_HAVE_ARG" is affected by this, but Python
scripts are shielded from that because the interface of the posix
module is the same regardless of the value of this macro.

We'd still end up with a build-hell when we'd want to provide a 4-way
universal build that can run on 10.4 as well, because 64-bit code is
always in UNIX03 mode, while 32-bit code that needs to run on 10.4
cannot be. I have some idea's about how to work around that issue,
but need time to investigate the viability of those ideas.

Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20090215/17948bc5/attachment.bin>

More information about the Python-Dev mailing list