Hi,
On 2021-10-15 15:36:16 -0700, Andres Freund wrote:
> On 2021-10-15 11:50:30 -0700, Andres Freund wrote:
> > 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.
>
> I implemented this for the meson build, and it seems to work nicely. The macos
> part was harder than I hoped due to the install_name stuff, which meson
> doesn't solve.
>
> https://github.com/anarazel/postgres/commit/a35379c28989469cc4b701a8d7a22422e6302e09
>
> After that the build directory is relocatale.
Well, now that I think about it, it's still only relocatable in the sense that
postgres itself will continue to work. Outside code linking to e.g. libpq will
get the wrong path after relocation the source tree, due to the absolute
install_name.
But that doesn't seem solvable, unless we make the installed install_name to
be '@rpath/libpq...dylib' and require code linking to libpq to pass
-Wl,-rpath,/path/to/libpq when linking to libpq.
Greetings,
Andres Freund