libgcrypt1.9.0: Failure on linking test executables

NIIBE Yutaka gniibe at
Fri Jan 22 13:02:50 CET 2021

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.

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.

The change of mine for minimizing library dependency has its purpose to
keep up evolusion of toolchain.

Ideally, libtool itself should have been evolved, while toolchain has
been evolved gradually.

More information about the Gcrypt-devel mailing list