Ok, I was a good boy and tried -interfaces first. No answer.

I'm trying to get a functioning version of plpython on FreeBSD, while
using python from the ports system.

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.

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.

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.

The ideal solution would be to build PostGreSQL with thread
support. I'd rather not find out the hard way that this doesn't
work. Does anyone know whether or not I can do that without mangling
PostGreSQL?

Alternatively, getting a statically linked version of plpython built
would mean I could delete the shared library. Anyone have any clues on
how to go about getting plpython built with a statically linked
libpython?

If there's another approach that might work, I'd be interested in
hearing about that as well.

	Thanks,
	<mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Mon, 17 Mar 2003 19:36:58 -0600
Mike Meyer <mwm@mired.org>
Threaded Python vs. PostGreSQL plpython
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


Mon, 24 Mar 2003 15:28:15 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: Threaded Python vs. PostGreSQL plpython