[Pythonmac-SIG] Extensions for static versus framework MachoPython

[Jack Jansen]

On vrijdag, juli 5, 2002, at 10:37 , bill fancher wrote:
>> I'm not sure why it doesn't complain, it may have something to 
>> do with Python.framework being linked with -flat_namespace, 
>> which it needs because it needs access to _environ (which 
>> frameworks or dynamic libraries don't get, sigh, only main 
>> programs).
>
> It doesn't complain because the *modules* are linked with 
> -flat_namespace,
>  so they know what libraries they "need" but not which library 
> a particular symbol comes from.

Aargh, you're right! Silly me, now if I can only remember why 
this is. I'll try changing it, maybe it was just an oversight...

> As for _environ, there's a way around that. From Mach-O Runtime 
> Architecture, p.24:

Tried this, but didn't get it to work without major surgery to 
the Python core (removing all direct references to the _environ 
global). Because when I simply added a global _environ to 
Python.framework I couldn't link the interpreter anymore because 
of the multiply-defined _environ (one from Python.framework, one 
from crt0).

> Assuming the PYTHON_API_VERSION	varies with what Apple calls 
> major versions (as it does in Python 2.2 vs. 2.3), then it 
> should be safe. I'd rather have the module not get linked 
> against the library, but use -flat_namespace -undefined 
> suppress. That keeps dyld from looking for a library that might 
> not be needed and might not even be there. That patch I sent 
> you off list that allows one to build Python as a standalone 
> dynamic shared library uses that approach, and doesn't have the 
> problem discussed here.

[I hadn't replied to your mods yet, as I didn't get around to 
it, but I might as well do so now]

I know, but it has a major problem in that -flat_namespace will 
take any symbol with the correct name and simply assume it is 
the symbol needed. This is an accident waiting to happen, and 
I'm heavily opposed to it. I know that for unix-Python this is 
the norm, but it leads to very obscure bugs.

And note that these bugs aren't theoretical, either. I've been 
bitten by it twice over the years, once because both SGI's 
original GL library and curses had a clear() function, and once 
because the SGI compression library contained a modified version 
of the IJG JPEG library with unmodified external names so 
anything that was linked against the normal jpeg library would 
be dead.

The first case (some Python script importing both the gl and 
curses modules) happened in exactly one Python script in the 
world: test.regrtest. The second case was really nasty, though, 
because image processing apps might easily import both PIL and 
cl without being aware of it. I'm very glad that MacPython has 
never had these problems (because external symbol and library 
are matched up), and so when Apple made this functionality 
available for OSX with the two-level namespaces I immediately 
jumped on the bandwagon.

But again: if enough people here feel that the benefits of 
-flat_namespace outweigh these problems, please speak up! I'm 
always will to (grudgingly:-) bend to the majority...

I have a completely unrelated problem with your patch (maybe you 
should post it to sourceforge as Tony suggested?) and that is 
that you build the shared library in /usr/local and then symlink 
to it from the Python.framework. In my opinion this defeats the 
purpose of using the framework in the first place, and that is 
having everything contained in a single location, so that 
install/uninstall becomes a trivial copy or remove. From 
historical data (usage of MacPython and Python on Windows) I 
assume that most OSX Python users will not build Python from 
source, and will probably not have installed the developer tools 
(they may not even have them if their OSX came bundled with 
their machine). I want MachoPython to make life easy for these 
people primarily, as the people who build from source are 
probably also more knowledgeable.

The question is really one of "should MachoPython behave like a 
Macintosh package or like a unix package", and my answer would 
be "like a Macintosh package". If you want the more traditional 
unix behavior you can ignore the whole framework business and do 
"configure; make" and have a perfectly normal unix Python on 
your OSX box.

--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -