Alexander Asteroth <alexander.aster...@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
