[Pythonmac-SIG] building extensions that link against dynamic libraries - Fixed!

[Bob Ippolito]

On Apr 26, 2004, at 5:58 PM, Jack Jansen wrote:

> On 26 Apr 2004, at 22:14, Ronald Oussoren wrote:
>>> You can simply change the linker flags that distutils uses by sudo  
>>> editing the LDSHARED (definitely) and BLDSHARED (maybe) definitions  
>>> in:
>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>>> python2.3/config/Makefile
>>
>> If you're really sick you can get the same effect by some sneaky  
>> Python code.
>
> We need *something* like this to implement Bob's idea of using  
> dynamic_lookup to fix the two-python problem, and while this solution  
> is better than what I have now (which is absolutely nothing) I'm not  
> 100% satisfied with it.
>
> The main problem I have is that the .pth trick means that this code  
> will be run in every single Python invocation. In other words, every  
> run of Python  will start off by fiddling with the distutils internals  
> (with all the side effects and imports and such that this concurs).  
> Does anyone have any smart ideas on how we could  fix this, so we only  
> execute this code when distutils is actually used?

You're mistaken, actually.  It fiddles with sys.path on every python  
invocation, nothing more.  It poses for the original distutils, and  
uses pkgutil to bring the original distutils in when it gets imported.

> For 2.4 we can fix this once and for all by having distutils try and  
> do an "import distutils_hotfix" in __init__, but that doesn't help us  
> for apple-installed 2.3.

It's more complicated than that.. there are three situations:
	(a) building on 10.3+ for 10.3+
		currently supported configuration
		use the fix
	(b) building on 10.3+ for 10.1+ with a 10.1+ safe Python
		currently unsupported but people want this
		reluctantly use -framework Python
		use a different fix (set NEXT_ROOT, lower MACOSX_DEPLOYMENT_TARGET)
	(c) building on < 10.3
		currently supported configuration
		can not use the fix
		reluctantly use -framework Python

TODO:
	Whatever version of Python that ships with OS X 10.4 should support  
ONLY situation (a).  This means that with default configuration options  
(or possibly just MACOSX_DEPLOYMENT_TARGET >= 10.3 introspection), the  
next releases of Python 2.3 and 2.4 should build for (a).

	Hot-fix should be available for OS X 10.3 python to support ONLY  
situation (a) [OS X 10.3 python is not 10.1+ safe anyway].  Ronald's  
pkghack is adequate for this.

	Some separate distribution and configure flag (or possibly just  
MACOSX_DEPLOYMENT_TARGET <= 10.2 and NEXT_ROOT introspection) of Python  
should be created to support situation (b).

> I also have slight misgivings about the way the script will fix any  
> distutils that comes on its path (I would prefer to fix only things  
> we're 100% sure we can fix), but that's easy to change.

I wouldn't be terribly worried about this.. how many distutils are  
there? And how many of those distutils aren't just slight modifications  
to the current?

-bob