libgcrypt1.9.0: Failure on linking test executables

[Kasumi Fukuda]

On Fri, Jan 22, 2021 at 9:02 PM NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Kasumi Fukuda wrote:
> > My understanding is that libgcypt and libgpg-error use libtool, so
> > RPATH (or RUNPATH) for the dependent libraries can be automatically
> > injected into the executable when linked.
> > We usually don't need to set LD_LIBRARY_PATH to run such an executable.
>
> Yes and No.
>
> For a program (like ones under tests) which is built with libtool's
> -no-install option, RPATH/RUNPATH is embedded.  That's true.  This is
> because such a program can be executed correctly with the particular
> library currently being built (not with the one installed already on
> system).
>
> With embedded RPATH/RUNPATH, such a program can be executed with no
> setting of LD_LIBRARY_PATH.  But, AFAIU, it is not for supporting no
> setting of LD_LIBRARY_PATH.

I didn't know that.

> Please note that LD_LIBRARY_PATH is usually set to run a program with
> library under non-standard prefix.  We can't ignore this major use case.
>
> > But this way of building GnuPG suite has been working for older
> > versions and it would be inconvenient if LD_LIBRARY_PATH were required
> > to be set.
>
> People would say it's a regression, I'm afraid.  I think that this is a
> corner case.

I agree that this is just a corner case with quite an old linker, and
respect your decision not to support them.

Thank you again for your clarification.