Re: Use relative rpath if possible - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Use relative rpath if possible
Date
Msg-id CA+hUKGKFX3E1cQRo6nCR7m-e12yqv7LKDuW=igSV1HTeoidD6w@mail.gmail.com
Whole thread Raw
In response to Re: Use relative rpath if possible  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: refactoring - share str2*int64 functions
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Multivariate MCV list vs. statistics target