Thread: Use relative rpath if possible
On several popular operating systems, we can use relative rpaths, using the $ORIGIN placeholder, so that the resulting installation is relocatable. Then we also don't need to set LD_LIBRARY_PATH during make check. This implementation will use a relative rpath if bindir and libdir are under the same common parent directory. Supported platforms are: freebsd, linux, netbsd, openbsd, solaris Information from https://lekensteyn.nl/rpath.html (Yes, something for macOS would be nice, to work around SIP issues, but I'll leave that as a separate future item.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
rebased patch attached, no functionality changes On 2019-06-27 13:45, Peter Eisentraut wrote: > On several popular operating systems, we can use relative rpaths, using > the $ORIGIN placeholder, so that the resulting installation is > relocatable. Then we also don't need to set LD_LIBRARY_PATH during make > check. > > This implementation will use a relative rpath if bindir and libdir are > under the same common parent directory. > > Supported platforms are: freebsd, linux, netbsd, openbsd, solaris > > Information from https://lekensteyn.nl/rpath.html > > (Yes, something for macOS would be nice, to work around SIP issues, but > I'll leave that as a separate future item.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
Peter Eisentraut <peter.eisentraut@2ndquadrant.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
sharedobject 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
I wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.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.
Oh ... just thought of another issue in the same vein: what about
modules being built out-of-tree with pgxs? (I'm imagining something
with a libpq.so dependency, like postgres_fdw.) We probably really
have to keep using the absolute rpath for that, because not only
would such modules certainly fail "make check" with a relative
rpath, but it's not really certain that they're intended to get
installed into the same installdir as the core libraries.
regards, tom lane
On Mon, Jul 8, 2019 at 2:01 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: > > Peter Eisentraut <peter.eisentraut@2ndquadrant.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. > > Oh ... just thought of another issue in the same vein: what about > modules being built out-of-tree with pgxs? (I'm imagining something > with a libpq.so dependency, like postgres_fdw.) We probably really > have to keep using the absolute rpath for that, because not only > would such modules certainly fail "make check" with a relative > rpath, but it's not really certain that they're intended to get > installed into the same installdir as the core libraries. There were a number of problems flagged up in Tom's feedback and then silence. I think this belongs in the 'Returned with feedback' box, so I've set it to that, but of course feel free to set it to 'Needs review' and thence 'Move to next CF'. -- Thomas Munro https://enterprisedb.com