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

[Tony Lownds]

At 09:35 AM 10/2/2000 +0200, you wrote:
> > test_fcntl
> > dyld: ./python.x multiple definitions of symbol _initfcntl
> > Modules/fcntlmodule.so definition of _initfcntl
> > Modules/FCNTLmodule.so definition of _initfcntl
>
>Where did FCNTLmodule.so come from? I don't have source for it in my
>tree, and a module with that name is not built on Linux.

Its actually loading fcntlmodule.so - I'm running Mac OS X on a 
case-insensitive filesystem, HFS+...

> > make install has more problems:
> > - it skips installing the shared library, because it checks for the 
> wrong extension (this is from the output of make install):
> >
> > if test -f libpython2.0.so; then \
> >                 ./install-sh -c -m 644 libpython2.0.so /usr/local/lib; \
> >         else    true; \
> >         fi
>
>Can somebody please summarize the meaning of file name extensions on MacOS?

On Mac OS X, they mean as much as on Unix....

>Is it essential that the file has a .dylib extension?

No, the shared modules are still named .so!

>Is it also necessary to use the .so extension for some other purpose?
>configure.in defines a @SO@ variable, which (I guess) gets the value
>of "so" on MacOS X.

Yep, it is set to .so; some of the other shared libraries not in frameworks 
that I found were .dylib
so I guess .dylib is better.

> > Basically, it finds the path P where libpython2.0.dylib is loaded
> > from, and assumes P/../lib is the standard library location. Maybe
> > the semantics of NSLibraryNameForModule have changed between Next
> > and Darwin - I think a clean fix of this problem would require
> > changes to the code above.
>
>Perhaps you have installed libpython20.dylib into the wrong location?
>It somehow assumes that the "framework" (whatever that is) is capable
>of dealing with multiple versions, and finding them in different
>locations.

I checked for extraneous libpython2.0.dylib files; I only have the one 
installed by the Makefile.
After a few days of playing with Mac OS X, that seems to be exactly what 
they are for.
They are directories in /System/Library/Frameworks/ with this structure:

XXX.framework/XXX -> Versions/Current/XXX
XXX.framework/Versions/
XXX.framework/Versions/Current -> YYY
XXX.framework/Versions/YYY/
XXX.framework/Versions/YYY/XXX
XXX.framework/Versions/YYY/

The actual shared library is named, e.g. Python, and YYY would be e.g. 2.0; 
Mac OS X system libraries have versions like "A", "B"

So far I haven't had any luck making a "Python" framework - it can be found 
at link time with the
-framework option to ld but not at run time.

>It's strange, though, that they assume the library will be in "lib".
>Even if libpython2.0.dylib was in /usr/local/lib/python2.0, that would
>mean that that the LANDMARK would need to be in
>/usr/local/lib/python2.0/lib/string.py. Perhaps the python.framework
>was intended to contain the Python lib as well?

That seems to be the idea; with header files in there as well.

>Otherwise, I'd say that the WITH_NEXT_FRAMEWORK part looks quite
>broken - you may consider not using it, after all, and arrange to
>achieve its desirable effects by some other means.

Quite right - the best option may be to allow for --with-next-framework 
(the configure option) w/o WITH_NEXT_FRAMEWORK (the #define).

Thanks for your insights,

-Tony Lownds