Re: State of PL/Python build

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> We already know about the libpython (not-)shared library issue. As it
> turns out, not only is libpython generally not a shared library, there
> isn't even a designed in way to make one.

Ugh. Can we get the Python boys to raise their level of concern about
that?

> The way it's currently set up is that it will use whatever linking with
> -lpythonx.y gives you. Using the static library this way works on many
> platforms, although it's not as efficient (each backend process image will
> have its own copy of the library).

Huh? As I understand it, what will happen is that libpython.a will get
physically incorporated into plpython.so (.sl, whatever). So all
Postgres backends that are using plpython should share one copy of that
library. It won't be shared with non-Postgres python processes, but
it's not nearly as bad as "one copy per backend".

The real problem is that on systems where non-PIC code can't be used to
build a shared library, the whole thing will not work at all. As with
plperl, it'd be nice if we could detect this at configure time.

I wonder whether people would like an option to statically link
libperl.a and/or libpython.a into the Postgres backend proper? That
would allow plperl/plpython to be used on platforms where this is an
issue, without having to make a nonstandard build of perl/python.

> The real fix is to change the dynamic loader(s) to make use of the
> RTLD_GLOBAL flag, which makes all dlopen'ed symbols available to everyone.
> Personally, I don't see any harm in using this option. Does anyone else?

No, on the platforms where it solves the problem...

> Resolving this issue on non-dlopen platforms is left as an exercise.

As near as I can tell from the man page, HPUX's shl_load behaves this
way all the time. Don't know about other non-dlopen platforms.

regards, tom lane