[Pythonmac-SIG] Re: Python on Mac OS X w/shared modules

[Martin v. Loewis]

> I don't think killing the code is good. I think it just needs
> someone with more Next/Mac OS X knowledge to make it really useful
> code.

Since nobody stepped forward in the past few years, perhaps no such
person exists (anymore)? Unmaintained code is not a problem as long as
it is not in the way. Now, it appears that the code is in the way, so
it needs to be fixed or removed.

> a) fixes the platform recognition code in configure (and configure.in) to 
> recognize Mac OS X as "darwin/1.2"

I'm confused. I thought that darwin was the name of a free BSD
personality on top of MacOS X, and that the "official" MacOS X tools
are different from the Darwin ones. Is that the case? and do the
official tools behave like the Darwin tools for building Python.

> b) made it so that just specifying --with-dyld= will make working shared 
> modules (basically, adds "-undefined suppress" to ld step)

In bug report 115641
(http://sourceforge.net/bugs/?func=detailbug&bug_id=115641&group_id=5470)
the reporter claims that this will result in undefined symbols
__eprintf and _environ when libtools is invoked. Can you see what his
error was? How did you address this problem?

[It appears that he simultaneously build with --with-next-framework
 and added -undefined suppress - maybe that was the error]

> These changes to configure are pretty straightforward because they just 
> modify existing steps of the configure process. Its at 
> http://tony.lownds.com/macosx/ page.

These patches look pretty good to me(*) - especially as they
apparently don't interfere with any other configuration, so they can
only improve things. Would you like to submit them to
sourceforge.net:/projects/python?

> How do you think the FCNTL.py / fcntlmodule.so problem can be solved?

Why isn't that a problem on MacOS 8? Let me guess: it does not provide
fcntl. If so, you could provide this as a work-around: disable fcntl.
Or else, rename it to _fcntl, provide an fcntl.py, and live with the
fact that you can't also import FCNTL. Or, fcntl.py could check
whether its __name__ is 'FCNTL' and import something else instead.
Such changes would affect other ports - so they'd fall in the "hack"
category...

On the case-insensitive case-preserving variants of DOS file systems
(i.e. VFAT), opening a module involves reading the directory to see if
the case on disk is the same as the expected case, see
import.c:case_check. So if HFS is also case-preserving, a similar
approach might work.

Regards,
Martin