This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jrevans
Recipients
Date 2003-11-11.16:29:47
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
The shared library is built and linked incorrectly resulting 
in errors.

The proper method for linking a shared library is to link it 
against all libraries it is dependant upon.  This puts 
entries into a shared library's dependency table (which 
can be seen using 'ldd' on linux or 'objdump' on other 
systems).

The result of this is that any application that is linked 
againg a particular library does not need to be aware of 
any of its dependencies at link time, it merely links 
against what it is directly dependant upon.  This can be 
thought of as building a dependancy tree.

Getting a full list of all libraries an executable (or shared 
library) are dependant upon is as simple as using 'ldd' as 
this will list the full dependancy tree.

The problem with the python shared library is that it is 
not linked during your build process against any of the 
libraries it is dependant upon.  For example when 
building with the tk, readline, and expat modules 
compiled into python, the library needs to be linked 
against the respective libraries.

In this way the shared library resolves all of its own 
dependancies.

This is something that I have been doing for several 
years, including always having rebuilding the python 
library as a shread library by hand.  For example:
> ar -x libpythonX.X.a
> g++ -shared *.o -o libpythonX.X.so -L/path/to/libs -
lexpat -lreadline -ltk

however since you have introduced the configure flag 
for shared library support (finally) it would be nice to be 
able to use it.
History
Date User Action Args
2008-01-20 09:56:32adminlinkissue840065 messages
2008-01-20 09:56:32admincreate