libgcrypt1.9.0: Failure on linking test executables
kasumi at rollingapple.net
Fri Jan 22 14:21:16 CET 2021
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
> 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.
More information about the Gcrypt-devel