Re: pg_upgade vs config

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgade vs config
Date: 2016-10-02 17:33:48
Message-ID: 28567.1475429628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-10-02 17:53:34 Re: pg_upgade vs config
Previous Message Tom Lane 2016-10-02 16:54:05 Re: pg_upgade vs config