Philip McGrath schreef op za 07-05-2022 om 14:39 [-0400]:
> With the caveat that all analogies are imprecise, why does Guix prefer 
> to avoid relying on LD_LIBRARY_PATH for C libraries?

Because when using LD_LIBRARY_PATH, you not only need to install the
binary in a profile, but also it library dependencies.  Now, suppose
that Guix didn't use RUNPATH or RPATH and instead relied on
LD_LIBRARY_PATH.

Now suppose you have a binary 'vlc' in /usr/bin (on a foreign distro)
and 'openssl.so' in ~/.guix-profile/lib/... . Note that 'vlc' has
'openssl' as a dependency (for streaming over the Internet).

Then suppose you run 'vlc'.  The dynamic linker will see ‘we have a
$LD_LIBRARY_PATH, let's use the openssl.so from ~/.guix-profile/lib
instead of /usr/lib!’.  However, it (could) turn out that the openssls
from the two different locations have an incompatible ABI, causing a
crash or such.

Also, if you depend of LD_LIBRARY_PATH (without wrap-program), then you
can't run things directly from /gnu/store.

In the same manner, GUILE_LOAD_COMPILED_PATH (= Guile's mix of
LD_LIBRARY_PATH (for 'guile') and LIBRARY_PATH (for Guile's compiler,
e.g. the cross-module inlining) is a bit suboptimal, Guile binaries
need to be wrapped (wrap-program / wrap-script).  Would be nice to have
a RUNPATH/RPATH equivalent ...

Greetings,
Maxime.