LD_LIBRARY_PATH issues when compiling package

LD_LIBRARY_PATH issues when compiling package

[Alexander Asteroth]

Dear all,

I've had an installation of python3.{11,12} on my guix system that 
worked for a few months now, installed using a minimalistic 
package description (see [0] at the end of this post).
After updating my guix installation two days ago it stopped 
working whith weird `pip3` errors concerning `module '_ctypes' not 
found`.
Rolling back to the old environment didn't help. 

Trying to find out what caused the error I compiled python3.11.7 
in my home environment and noticed a warning that in fact the 
`_ctypes` module was disabled after compilation because the 
`libffi` library wasn't found (even thought it was installed).

Changing the configuration to:
```
$ ./configure --enable-optimizations --prefix="$HOME/.local/" 
LDFLAGS="-L$HOME/.guix-profile/lib"
```
did resolve the issue resulting in a working local installation.

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

Cheers and Merry Christmas

Alex

----

[0] python.scm:
```
(define-module (gyps packages python)
   [...] ;; cut out for brevity
)

(define-public python
  (package
   (name "python")
   (version "3.11.7")
   (source
    (origin
     (method url-fetch)
     (uri (string-append "https://www.python.org/ftp/python/"
                         version "/Python-" version ".tgz"))
     (sha256 (base32 
     "02cjn89mplkglgbsm5s9by7qaa1ii3x8sickpm0pdrb24bw0b306"))))
   (build-system gnu-build-system)
   (arguments '(#:tests? #f))
   (inputs
    (list bzip2
          expat
          gdbm
          libffi 
          sqlite 
          openssl
          readline
          zlib
          tcl
          tk))   
   (native-inputs
    `(("pkg-config" ,pkg-config)
      ("sitecustomize.py" ,(local-file (search-auxiliary-file
                                        "python/sitecustomize.py")))
      ))
   (home-page "https://www.python.org")
   (synopsis "High-level, dynamically-typed programming language")
   (description "[...]")
   (properties '((cpe-name . "python")))
   (license license:psfl)))   
```

Re: LD_LIBRARY_PATH issues when compiling package

[Ian Eure]

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