Python Un*x build with a Python shared library

Frederic Giacometti frederic.giacometti at
Tue May 15 15:06:29 CEST 2001


Building Python with a shared library on Unix seems to be a recurring

I made my homework and scanned the archives.
So, let me summarize here what seems to be the issues:

When is a unique Python shared library  needed?

-> In situations where Python is embeded in a non-python application,
and that the Python thread must be re-entered during callbacks to the
    - the same Python thread must be reentered
    - there must be a unique Python interpreter lock in the process, and
not one different interpreter lock for each copy of the static library
that has been duplicated in many places.

In such case, using a Python shared library insures that all functions
of the process adress the same Python global variables (amongst which
the Python interpreter lock, and current thread).

Note that on windows, the python library is shared....

At present I know of at least three applications that require Python
build on a shared library: JPE (Java-Python extension), Metadynamic
(Metaphase-Python integration), and the eMatrix-Python integration (I
developped the three of them, actually).

What are the problems with building python with a shared library on

- Portability, platform-specific features, lack of maturity on some Unix

-> Albeit introduced only a few years ago on most Unixes, shared library
technology is now reliable and mature on all current Unix platforms
(even on HP-UX :)).
This should not be an issue anymore on all current Un*x.

Issues and impact of a Python shared library build on Un*x

For what I know:

- On Hp/UX and Tru64: works fine

- On Linux and FreeBSD: there is the issue with the -export-dynamic
option that must be used when building the main executable.
Yet, in some situations (e.g. when imbeding Python in Java, as in JPE),
you cannot re-link the main executable (Java...).
This requires relinking all dynamic Python extension with the Python
shared library.
Currently, this can be solved by patching the distutil code for this

So, provided that that all dynamic Python extensions are linked to the
Python shared library in their build for all platforms (like it is
already the case on Windows), everything should be all right.

Changes requested on the current Python 2.1 source distribution:
Changes should be required in only two location:
    - main Python Makefile
    - the distutil code that links the dynamic extensions.

Progress status:
The patch for building Python 2.1 around a 'python2.1' shared library
will be requested for running the Java-Python Extension (JPE) on


More information about the Python-list mailing list