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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
