Re: Use relative rpath if possible

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> rebased patch attached, no functionality changes

I poked at this a bit, and soon found that it fails check-world,
because the isolationtester binary is built with an rpath that
only works if it's part of the temp install tree, which it ain't.

/home/postgres/pgsql/src/test/isolation/isolationtester: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory

(The cfbot seems to get past that, for reasons that are entirely unclear
to me; but it falls over later in the ecpg tests with what's presumably
the same problem.)

While there might be some argument for making isolationtester part
of the installed set of executables, that approach certainly doesn't
scale; we can't insist that every test tool should be part of the
installation.

So I think we need some more-intelligent rule about when to apply
the relative rpath. Which in turn seems to mean we still need to
set up LD_LIBRARY_PATH in some cases.

Another thing I noticed is that if, say, you build a new version
of psql and try to test it out with "./psql ...", that doesn't work
anymore (whereas today, it does work as long as you installed libpq
earlier). That might be acceptable collateral damage, but it's not
very desirable IMO.

I'm also slightly concerned that this effectively mandates that every
library we install be immediately in $(libdir), never subdirectories
thereof; else it'd need more than one ".." in its rpath and there's no
way to adjust that. That's not a showstopper problem probably, because
we have no such libraries today, but I wonder if somebody would want
some in the future.

A possible partial solution to these issues is to make the rpath look
like $ORIGIN/../lib and then the normal absolute rpath. But that
doesn't fix the problem for non-installed binaries used in check-world
with no pre-existing installation.

>> (Yes, something for macOS would be nice, to work around SIP issues, but
>> I'll leave that as a separate future item.)

TBH, I think that supporting macOS with SIP enabled is really the
only interesting case here. On these other platforms, changing this
won't fix anything very critical, and it seems like it will make
some cases worse.

regards, tom lane