Re: Use relative rpath if possible

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use relative rpath if possible
Date: 2019-08-01 08:28:50
Message-ID: CA+hUKGKFX3E1cQRo6nCR7m-e12yqv7LKDuW=igSV1HTeoidD6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 8, 2019 at 2:01 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > 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.
>
> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2019-08-01 08:29:20 Re: Multivariate MCV list vs. statistics target
Previous Message Michael Paquier 2019-08-01 08:23:17 Re: refactoring - share str2*int64 functions