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.
Logged In: YES user_id=21627 Would you be willing to contribute a patch? This feature is essentially unmaintained, and only updated when users contribute updates.
