[Distutils] 2 platforms down, only Mac to go...

[Bob Ippolito]

On Jan 16, 2006, at 6:09 PM, Phillip J. Eby wrote:

> At 03:32 PM 01/16/2006 -0800, Bob Ippolito wrote:
>
>> On Jan 16, 2006, at 3:21 PM, Michael Twomey wrote:
>>
>>> On 14/01/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>>>
>>>> I wonder, though, if perhaps what's happening in the configuration
>>>> that
>>>> currently works, is that the path is being interpreted as "bundle
>>>> relative"
>>>> to the extension.  This is fine and is really what we want, but
>>>> I'm not
>>>> sure that it can be done with older Mac OSes.  I seem to recall  
>>>> that
>>>> bundle-relative linking was added in 10.4?  Or was it 10.3?  I
>>>> need to
>>>> start actually *using* a Mac one of these days.  :)
>>>
>>> I think it was in 10.3 (the MACOSX_DEPLOYMENT_TARGET affects this),
>>> I'm pretty sure it was the "-undefined dynamic_lookup" which got
>>> introduced, which had a big impact on shared libraries in  
>>> bundles. I'm
>>> not sure how this would affect the linking stuff above, it is  
>>> "used to
>>> allow any undefined symbols to be looked up dynamically at runtime"
>>> according to the man page.
>>
>> You are correct, MACOSX_DEPLOYMENT_TARGET=10.3 allows you to use -  
>> undefined dynamic_lookup.  However, requiring Mac OS X 10.4 would
>> allow you to use @loader_path [1], which would let you skip out on
>> the chdir hack.
>>
>> [1] http://developer.apple.com/releasenotes/DeveloperTools/dyld.html
>
> So, should setuptools maybe check the deployment target and use  
> that to decide whether to chdir-hack or to use -install_name  
> @loader_path/blah.dylib?  That won't make the current platform  
> tests and build customization any more complex on a fundamental  
> level.  I already have to decide whether to use a chdir loader (not  
> needed at all on Windows) and whether the loader should use dl  
> (Linux) or not (Mac).  So, adding an environment variable check  
> doesn't sound like a big deal.

Apple has actually shifted their recommended runtime dynamic linkage  
API to plain old dl.. it's part of libc in Mac OS X 10.4, available  
for dynamic linkage in Mac OS X 10.3, and provided as a static  
library for earlier versions of OS X.  It might be worth considering  
shifting Python 2.5 towards that API instead of the old NeXT-style  
APIs.  I don't want to do that work, of course, the APIs are  
equivalent and what we have works.

Personally I'd probably just go with the chdir loader for now,  
because people are still running 10.3.  In a year or two, it might be  
worth dropping 10.3 support and switching over to @loader_path and  
removing the cruft.  Until then, I don't see the benefit of  
maintaining two code paths.

> Do any OS X versions prior to 10.3 even have Python installed,  
> btw?  I'm figuring I can live with not supporting those, though I  
> should double-check what OSAF is targeting, of course.

OSAF is not going to want to target any vendor-installed Python.   
They should be bundling a self-contained Python installation with  
Chandler (as I'm sure they do on Windows, too).

If they do depend on a vendor-installed Python, they'll have to have  
separate versions of everything for almost every OS release.  I  
wouldn't even worry about it.

To answer your question, 10.2 had a horrifically bad build of Python  
2.2.0.

-bob