Date: Fri, 15 Oct 2021 11:50:30 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
Cc: Thomas Munro <thomas.munro@gmail.com>,
	John Naylor <john.naylor@enterprisedb.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [RFC] building postgres with meson
Message-ID: <20211015185030.l43dcix5mltks235@alap3.anarazel.de>
References: <20211013163721.oqwvztktwsym3iu4@alap3.anarazel.de>
 <CAFBsxsEqZ1cCayUEd6nS7sS9Pv29G-hkJLbqE1wUmtG1AP4xcg@mail.gmail.com>
 <20211013174246.zgp2sxdqsulhepea@alap3.anarazel.de>
 <CAFBsxsF2oeU3VUkB-TtvuJXAvyxHAQcweHDPAO0EC=e4BgC=yQ@mail.gmail.com>
 <CAFBsxsHfwZYDUOa1+KuW21WDJr+ONscE5ATgvfEBO7mgJHuWPA@mail.gmail.com>
 <D0B73C41-FA4E-40B9-870E-60852CC9D2E2@anarazel.de>
 <906095.1634248849@sss.pgh.pa.us>
 <CA+hUKGJcPZoJgQuwF3NOxymg6KW6azChcjFXB4fgbLQFBSXy0A@mail.gmail.com>
 <20211014231501.vgmxc2jl63cya5ym@alap3.anarazel.de>
 <910266.1634253838@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <910266.1634253838@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20211015185030.l43dcix5mltks235%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2021-10-14 19:23:58 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > If, and perhaps that's too big an if, relative rpaths actually work despite
> > SIP, it might be worth setting a relative install_rpath, because afaict that
> > should then work both for a "real" installation and our temporary test one.
> 
> From what we know so far, it seems like SIP wouldn't interfere with
> that (if it works at all).  I think what SIP desires to prevent is
> messing with a program's execution by setting DYLD_LIBRARY_PATH.
> As long as the program executable itself is saying where to find
> the library, I don't see why they should interfere with that.

Well, there's *some* danger with relative rpaths, because they might
accidentally be pointing somewhere non-existing and user-creatable. Not a huge
risk, but as you say:

> (Again, it seems blindingly stupid to forbid this while not blocking
> PATH or any of the other environment variables that have always affected
> execution.  But what do I know.)

these aren't necessarily carefuly weighed considerations :/

But it seems to work well from what I gather.


> > If absolute rpaths are required, it'd make the process a bit more expensive,
> 
> It'd also put the kibosh on relocatable install trees, though I dunno how
> much people really care about that.

We currently use absolute rpaths, or something equivalent.

The reason that running tests on macos works is that we set the "install_name"
of shared libraries to the intended installed location, using an absolute
path:
    LINK.shared		= $(COMPILER) -dynamiclib -install_name '$(libdir)/lib$(NAME).$(SO_MAJOR_VERSION)$(DLSUFFIX)' $(version_link) $(exported_symbols_list) -multiply_defined suppress
which on macos means that all libraries linking to that dylib reference it
under that absolute path.

On most other platforms we set an absolute rpath to the installation
directory, which has an equivalent effect:
rpathdir = $(libdir)


It seems to work quite well to change our own references to libpq in binaries
/ shared libs to be relative, but to leave the install_name of the libraries
intact. In combination with adding an rpath of @loader_path/../lib/ to
binaries and @loader_path/ to shlibs, the install will re relocatable.

It doesn't work as well to actually have a non-absolute install_name for
libraries (e.g. @rpath/libpq.dylib), because then external code linking to
libpq needs to add an rpath to the installation to make it work.

The advantage of this approach over Peter's is that it's not temp-install
specific - due to the relative paths, it makes installations relocatable
without relying [DY]LD_LIBRARY_PATH.

On other unixoid systems this whole mess is simpler, because we can just add
$ORIGIN to shared libraries and $ORIGIN/../lib/ to binaries. We don't need to
leave some absolute path in the libraries themself intact.

Greetings,

Andres Freund