Python FAQ Page
(http://www.python.org/cgi-bin/faqw.py?req=show&file=faq03.030.htp)

3.30. Why is the Python interpreter not built as a shared library?
(This is a Unix question; on Mac and Windows, it is a shared library.)

It's just a nightmare to get this to work on all different platforms. 
Shared library portability is a pain. And yes, I know about GNU
libtool -- but it requires me to use its conventions for filenames
etc, and it would require a complete and utter rewrite of all the
makefile and config tools I'm currently using.

In practice, few applications embed Python -- it's much more common to
have Python extensions, which already are shared libraries. Also,
serious embedders often want total control over which Python version
and configuration they use so they wouldn't want to use a standard
shared library anyway. So while the motivation of saving space when
lots of apps embed Python is nice in theory, I doubt that it will save
much in practice. (Hence the low priority I give to making a shared library.)

For Linux systems, the simplest method of producing libpython1.5.so
seems to be (originally from the Minotaur project web page,
http://www.equi4.com/minotaur/minotaur.html):

  make distclean 
  ./configure 
  make OPT="-fpic -O2" 
  mkdir .extract 
  (cd .extract; ar xv ../libpython1.5.a) 
  gcc -shared -o libpython1.5.so .extract/*.o 
  rm -rf .extract

In Python 2.3 this will be supported by the standard build routine (at
least on Linux) with --enable-shared. Note however that there is little
advantage, and it slows down Python because of the need for PIC code
and the extra cost at startup time to find the library.

Edit this entry / Log info / Last changed on Thu May 30 13:36:55 2002 by GvR