This patch allows builing of libpython.so in addition 
to build libpython.a. The patch currently is used for 
building the python package on Debian GNU/Linux, so it 
needs to be cleaned up for other architectures. 
However python already has support for building shared 
libs, so this should not be a major problem. Feedback 
for a cleanup of the patch is appreciated.

Logged In: YES 
user_id=21627

The patch looks good (it is the third or so of its kind, but
I'm optimistic that it can be integrated this time).

Would you like to take another round of cleanup? Specifically:

- Building libpython as a shared library MUST be a
configuration-time option, this is not negotiable. On many
systems, building libpython as a shared library will cause
problems, since the directory containing libpython won't be
in the standard search path of the dynamic linker (e.g. in
/usr/local/lib on Solaris). Adding -R options helps, but not
much, since the binaries won't be relocatable with such
options. The options should default to "off" (static
linking); this is negotiable.
 
- It seems that the patch has a few unrelated changes. What
system is GNU* (I assume the Hurd?) Those should come in a
separate patch.

- Library versioning needs discussion. It seems that this
patch will give the library a name of libpython2.2.so.0.0.
Under which conditions should the SONAME be changed? If
2.2.1 comes along, how should the SOVERSION change? To 0.1?
Or to 1.0? I'd prefer to start with 1.0, anyway - procedures
to bump the SOVERSION still need to be discussed (I assume
bumping the minor version for Python micro releases should
be ok).

- If the option for building as a shared library is
activated, assume, by default, that the procedure on all
systems is identical, i.e. don't try to write Linux-specific
code. We can test it on many systems, and on others, users
simply can't activate the option. Please put assignments to
LDLIBRARY all in one place (there is already a section that
does so for dgux/beos/cygwin).

- What is the value of building both PIC and non-PIC
objects? If libpython is a shared library, I'd suggest to
put PIC objects into libpython.a, anyway. That would allow
to get rid of the pic_o objects. If some Debian policy says
a .a library must not contain PIC objects, I could live with
two compilations per source file.

- Put the computation of system-dependent options all in
configure.in. In particular, passing -soname should be done
in configure.in; that should probably be the same on all
systems building a shared libpython using GCC.

- Please don't use LD_PRELOAD. Using LD_LIBRARY_PATH seems
more sensible, IMO.

Logged In: NO 

It would be really helpful to have this patch applied. 
Certain uses of python are impossible without a python
shared library (usually involving a combination of extension
modules and embedding python).

The PyXPCOM bindings are one such example.  It looks like we
might run into a similar problem when writing bindings for
gnome-vfs.

In the gnome-vfs case, it allows loadable modules that
implement file systems.  One such module might be a wrapper
that passes on all gnome-vfs requests to python code.  It
would be a shared library, embedding a python interpreter,
and running python code.  This module would then be loaded
by any gnome-vfs using application when certain paths are
requested.  As there is no libpython.so, this vfs module
would be staticly linked to libpython, so it contains a copy
of the interpreter.

Now the gnome-vfs library would also be useful in python
applications (especially gnome ones, so that it uses the
same filesystem space as other apps).  This support would be
implemented as an extension for python.

Things get interesting when a python application uses
gnome-vfs to access a file handled by the python vfs module.
 There is one copy of the interpreter in the the main python
executable, and another in the vfs module.  This means
different bits of code may end up using different copies of
the interpreter (and we get two global interpreter locks,
etc, etc).  This leads to all kinds of problems.

With a shared libpython, both the vfs module and python
executable will be using the same interpreter, and all these
problems disapear.

Getting this patch into python distribution would be _very_
useful.

James Henstridge <james at daa dot com dot au>

Logged In: YES 
user_id=21627

In the current form, the patch is simply unacceptable. There
is no doubt that this feature has its applications; and
there is no need to lobby for it. Instead, fixing the
problems in the implementation of the feature would make a
difference.

Logged In: YES 
user_id=21627

This has been fixed with a similar patch in CVS.