[Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ronald Oussoren]

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:

/*
  * The __DARWIN_ALIAS macros are used to do symbol renaming; they allow
  * legacy code to use the old symbol, thus maintiang binary  
compatability
  * while new code can use a standards compliant version of the same  
function.
  *
  * __DARWIN_ALIAS is used by itself if the function signature has not
  * changed, it is used along with a #ifdef check for __DARWIN_UNIX03
  * if the signature has changed.  Because the __LP64__ enviroment
  * only supports UNIX03 sementics it causes __DARWIN_UNIX03 to be
  * defined, but causes __DARWIN_ALIAS to do no symbol mangling.
  *
  * As a special case, when XCode is used to target a specific version  
of the
  * OS, the manifest constant  
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
  * will be defined by the compiler, with the digits representing  
major version
  * time 100 + minor version times 10 (e.g. 10.5 := 1050).  If we are  
targetting
  * pre-10.5, and it is the default compilation environment, revert the
  * compilation environment to pre-__DARWIN_UNIX03.
  */

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>