Mike Meyer writes:
> The problem is that the ports system build python with thread
> support. postmaster doesn't have thread support, so when the
> libpython2.2.so is dynamically loaded, it fails to find the thread
> functions, and the load fails.
What is "thread support", what are "the thread functions", why does it try
to find them in the postmaster, and what are the exact details anyway?
> The first workaround I tried was to build a custom version of the
> python library that doesn't have thread support. Given that plpython
> won't let me import the thread modules, this isn't a problem. However,
> it does mean I have a copy of libpython2.2.so where they dynamic
> loader can find it, meaning the linker will find it, meaning that
> future builds of other embedded software - like apache's mod_python -
> will wind up with the non-threaded library. This is a bad thing, and
> I'd like to avoid it.
With judicious use of rpath you can keep several versions of a shared
libpython around without the dynamic loader getting confused.
> I tried building linking plpython.so against the static library
> instead of the dynamica library, but that doesn't work properly when
> loaded. I'm not sure what the problem is.
Possibly, the dynamic library would in turn automatically load some other
dynamic libraries, either because of implicit linkage or through the
run-time dynamic loading mechanism. If you have a static library, then
you miss all those things. Hard to tell without getting exact details,
though. I know on some platforms it has been shown to be possible to use
a static libpython for plpython.
--
Peter Eisentraut peter_e@gmx.net
