Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)

[Vincent Lefevre]

On 2022-09-06 11:17:27 +0200, Vincent Lefevre wrote:
> On 2022-09-06 10:12:23 +0200, Frederic Berat wrote:
> > The behavior is likely not due to patches on libtool (at least I
> > couldn't find anything obviously relevant), but more probably to the
> > default behavior of gnu ld.
> > From the behavior described in the thread earlier, it looks like
> > Debian has the "--enable-dtags" option set to ld, while Redhat doesn't
> > have it. That leads to RUNPATH being set on Debian while RPATH is set
> > on REDHAT, which by side effect modifies the behavior of libtool, if I
> > get it right.
> > 
> > Interestingly, Vincent opened a bug report in Debian a few years ago
> > [1], complaining that "--enable-dtags" was breaking tests generated by
> > libtool. I wonder if there was any follow-up on this, and what was the
> > conclusion.
> > 
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
> 
> Unfortunately, as you can see, there were no answers. So I ended up
> by explicitly disabling dtags for GNU MPFR (when supported):
[...]

I forgot to say that MPFR does not use wrappers, in particular
because it makes debugging a bit less easy, so that it is not
possible to get rid of LD_LIBRARY_PATH in "make check". Anyway,
getting rid of it would be incorrect, because this is where the
GMP library (which MPFR uses) may be found.

The main issue comes from the fact that LD_LIBRARY_PATH has 2 meanings:
  1. just add some path to the search path, typically based on
     the user's home directory, so that the user can install
     libraries in his homedir, and avoid the use of -L, etc.
     (possibly with a higher precedence than the system paths).
  2. override hardcoded runpath in some particular binaries.

It seems that RUNPATH was introduced to solve (2), while it should
have been much better to introduce something like LD_LIBRARY_PATH
but with a higher precedence (a bit like LD_PRELOAD, which can
already be used to solve (2), but maybe with some drawbacks).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)