unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* LD_LIBRARY_PATH issues when compiling package
@ 2023-12-25 11:24 Alexander Asteroth
  2024-01-03  0:39 ` Ian Eure
  0 siblings, 1 reply; 2+ messages in thread
From: Alexander Asteroth @ 2023-12-25 11:24 UTC (permalink / raw)
  To: help-guix

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)))   
```


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: LD_LIBRARY_PATH issues when compiling package
  2023-12-25 11:24 LD_LIBRARY_PATH issues when compiling package Alexander Asteroth
@ 2024-01-03  0:39 ` Ian Eure
  0 siblings, 0 replies; 2+ messages in thread
From: Ian Eure @ 2024-01-03  0:39 UTC (permalink / raw)
  To: help-guix


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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-01-03  0:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-12-25 11:24 LD_LIBRARY_PATH issues when compiling package Alexander Asteroth
2024-01-03  0:39 ` Ian Eure

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).