I wrote:
> I suspect the explanation is that macOS's dynamic linker is smart enough
> to pull in plpython when one of those modules is LOAD'ed. The ideal fix
> would be to make that happen on all platforms. I'm not actually sure
> why it doesn't already; surely every dynamic linker in existence has
> such a capability.
Some experimentation says that this is indeed possible on Linux, at least.
It's a bit of a pain because the .so's we need to reference are not named
"libsomething.so" and thus a straight -l switch doesn't work. The Linux
ld(1) man page documents that you can write "-l:filename" to override the
addition of "lib", but I have no idea how portable that is to other
toolchains. (On macOS, and maybe other BSD-derived systems, it looks
like you can do this without the colon, ie -lhstore.so will work.)
Also, it seems that -L../hstore -l:hstore$(DLSUFFIX)
which was my first attempt, doesn't work because you end up with a
hard-coded reference to "../hstore/hstore.so", which rpath searching
doesn't cope with. I was able to make it work by copying hstore.so
and plpython2.so into contrib/hstore_plpython and then just writing
SHLIB_LINK += -L. -l:hstore$(DLSUFFIX) \-l:plpython$(python_majorversion)$(DLSUFFIX) $(python_libspec)
That results in undecorated references that do work with the rpath.
This all seems depressingly platform-specific, but maybe we can make
it work on enough platforms to be satisfactory.
regards, tom lane