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

Martin v. Loewis martin@loewis.home.cs.tu-berlin.de
Mon, 2 Oct 2000 09:35:08 +0200


> 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.

> test test_format failed -- Writing: "'%#.117x' % (1,) == '0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001' != '0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001'", expected: ''

Must be a glitch in 2.0b2. The first string is only 117 characters
long; in the current test suite, it is 119 characters.

> 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?
Is it essential that the file has a .dylib extension? 
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.

That should be corrected in the Makefile. The fragment

		if test -f libpython$(VERSION).so; then \
			$(INSTALL_DATA) libpython$(VERSION).so $(LIBDIR); \
		else	true; \
		fi

should probably read

		if test -f libpython$(VERSION).$(LDEXT); then \
			$(INSTALL_DATA) libpython$(VERSION).$(LDEXT) $(LIBDIR); \
		else	true; \
		fi

where LDEXT is set to so on every system but MacOS... See below, though.

> 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.

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?

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.

Regards,
Martin