* 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
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.