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
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 |