Bug 127357

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-AU; rv:1.7)
Gecko/20040629 Firefox/0.9.1

Description of problem:
It would be nice if the python package in Fedora built with
--enable-shared, so that it builds libpython as a shared library
instead of a static library.

This has a number of benefits:

1. packages that embed Python won't need to be recompiled when a new
micro release of Python is released (eg. 2.3.1 -> 2.3.2)

2. Some combinations of embedding and extending are impossible with a
static library.

Consider the case of a library that can dynamically load plugins, and
that there is a Python extension module that allows the library to be
used from Python.

Now imagine if a plugin was written that embedded Python, allowing
plugin code to be written in Python.

When the library is used from a C program, the Python plugin will work
fine.  Similarly, the library can be used from the Python shell fine
as long as the Python plugin isn't used.

However, if you make use of the Python plugin while running from the
Python shell, things will break, since there will be two copies of
libpython in memory (the copy statically linked to /usr/bin/python,
and the copy statically linked to the plugin), and two sets of all the
global variables (including the global interpreter lock).

This problem could be avoided by building libpython as a shared
library, since everything would be using the same copy of Python.

This problem isn't completely theoretical.  One package that triggers
this problem is PyXPCOM, which allows you to implement Mozilla XPCOM
components in Python.  The components work fine when used from
Mozilla, but if you try to use them from the Python shell (using
PyXPCOM's XPCOM client bindings), things break.

The same problem would occur for Gnome-VFS modules implemented in
Python, as an example.