Re: LD_LIBRARY_PATH issues when compiling package

[Ian Eure <ian@retrospec.tv>]

Alexander Asteroth <alexander.asteroth@h-brs.de> writes:

> Dear all,
>
> (snip)
>
> Now I have basically three questions:
>
> 1. how can I advice the package build process (see [0]) to set 
> the 
> LDFLAGS correctly?
>    (shouldn't this be done by adding `(input [...] libffi [...] 
>    )` 
>    to the package description?)
>

For the few packages I’ve put together, adding the library to the 
package inputs has enabled the build to see and link against them. 
I don’t know the mechanics of how this works, but it seems to.

If your package requires the library at runtime (which sounds like 
it’s the case for you), it needs to be in propagated-inputs 
instead.


> 2. how do programs in a guix system find the libraries (which 
> reside in $HOME/.guix-profile/lib and in the store directories) 
> anyway?

The rpath[1] in the ELF header of compiled binaries it set to the 
store location of the libraries it’s linked against.  This is very 
easy to see on a foreign distribution with Guix installed.  Here’s 
one of my machines, which is running Debian, and has SBCL 
installed both via apt and guix:

meson!ieure:~$ readelf -d /usr/bin/sbcl | grep 'R.*PATH'
meson!ieure:~$ readelf -d ~/.guix-profile/bin/sbcl | grep 
'R.*PATH'
 0x000000000000001d (RUNPATH)            Library runpath: 
 [/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib:/gnu/store/3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/../../..]


> 3. does anybody have an idea what could have caused the library 
> not to be found anymore after an update of the packages?
>    (that even could not be resolved by rolling back to the old 
>    environment of before the change)

Hard to say, I don’t have a hypothesis.

  — Ian

[1]: https://en.wikipedia.org/wiki/Rpath