Bug 127357 - build libpython as a shared library
build libpython as a shared library
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Brock Organ
: FutureFeature
: 128133 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-07-06 21:44 EDT by James Henstridge
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.3.4-5
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-04 12:42:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Henstridge 2004-07-06 21:44:00 EDT
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.
Comment 1 Paul Nasrat 2004-07-12 11:31:46 EDT
This would benefit OOo as well.  Python 2.3 and later have an
--enable-shared to let us do build with libpython.so, a bit more work
than just dropping that in it seems:

'import site' failed; use -v for traceback
running build
running build_ext
running build_scripts
make[1]: Leaving directory
+ /home/pauln/src/pkgsrc/rpms/python/Python-2.3.4/python
Tools/scripts/pathfix.py -i '/usr/bin/env python2.3' .
/home/pauln/src/pkgsrc/rpms/python/Python-2.3.4/python: error while
loading shared libraries: libpython2.3.so.1.0: cannot open shared
object file: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.1054 (%build)
Comment 2 James Henstridge 2004-07-13 00:06:01 EDT
Hmm.  This is because it is trying to run the just-built Python
executable, but because libpython2.3.so.1.0 is in a buildroot, the
linker can't find it.  Possibly setting
LD_LIBRARY_PATH=%{buildroot}%{_libdir} during install would solve the

I suppose it is also worth noting that this is probably more important
on x86-64 systems, since there are a number of packages out there that
rely on the fact that you can link libpython.a into a shared object on
i386.  They all get link errors on x86-64.
Comment 3 Mihai Ibanescu 2004-07-19 10:57:09 EDT
*** Bug 128133 has been marked as a duplicate of this bug. ***
Comment 4 Mihai Ibanescu 2004-07-29 19:42:34 EDT
python 2.3.4-5 should have this fixed
Comment 5 Dominik Mierzejewski 2005-05-24 08:06:59 EDT
Is there any chance in seeing this fixed in Fedora Core 2 Legacy? I'm building
Openoffice.org 1.9.100 from FC4 SRPM and I'd prefer not to install python from FC3.

Note You need to log in before you can comment on or make changes to this bug.