[Python-Dev] _PyImport_LoadDynamicModule questions
David Abrahams" <firstname.lastname@example.org
Thu, 30 May 2002 07:58:18 -0400
From: "Martin v. Loewis" <email@example.com>
> Guido van Rossum <firstname.lastname@example.org> writes:
> > > If you find that a "good" redesign requires a shared libpython, then
> > > so be it - but I'm still quite fond of the "single executable"
> > > appraoch, so preserving that would be even better.
> > Why? I thought there was serious work underway to make libpython.so a
> > reality on Linux?
> It already is, with --enable-shared.
> However, I still think that people creating --enable-shared
> installations are misguided: You gain nothing
On AIX, you'd gain at least a little something: there would be no need to
"manually" patch up the symbol references the way
_PyImport_LoadDynamicModule is currently doing, and shared libraries that
were not themselves extension modules wouldn't have to duplicate that
functionality (as I understand you are saying they should in lieu of
hijacking the Python call). Whether that makes the separate shared library
worth it or not, I can't say. Probably not in light of the other benefits
you list here.
The AIX problem with resolving symbols from an executable is strange enough
that it can be a significant obstacle to porting systems built around
Python. The only way we figured it out was by crawling through the Python
source to figure out how the symbols were getting resolved. It would be
really nice if there were a "documented and stable" version of the core
functionality which is doing the symbol patching. Since Python is an
executable which expects to share its symbols with libraries, it's not
unreasonable to think that Python ought to provide the means to do it.
Coming up with a code patch wouldn't be too hard, I think, but where would
the documentation go?