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 on10.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 hasmuch 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- bitcode, or 64-bit code, no?I should have been more clear: the unix API for code that runs on10.4 is slightly different than that for code that runs on 10.5+, Applebasiclly 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 differentlyon 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
