GNU bug report logs -
#72395
[PATCH] syscalls: Support musl libc in openpty and login-tty
Previous Next
To reply to this bug, email your comments to 72395 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix <at> cbaines.net, dev <at> jpoiret.xyz, ludo <at> gnu.org, othacehe <at> gnu.org, zimon.toutoune <at> gmail.com, me <at> tobias.gr, guix-patches <at> gnu.org
:
bug#72395
; Package
guix-patches
.
(Wed, 31 Jul 2024 09:44:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
soeren <at> soeren-tempel.net
:
New bug report received and forwarded. Copy sent to
guix <at> cbaines.net, dev <at> jpoiret.xyz, ludo <at> gnu.org, othacehe <at> gnu.org, zimon.toutoune <at> gmail.com, me <at> tobias.gr, guix-patches <at> gnu.org
.
(Wed, 31 Jul 2024 09:44:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Sören Tempel <soeren <at> soeren-tempel.net>
Contrary to glibc, musl does not define the openpty and login-tty
function in libutil.so. In fact, libutil.so does not exist on musl-based
Linux distributions. Therefore, on musl-based systems we don't have
to pass any #:library keyword argument to syscall->procedure.
---
guix/build/syscalls.scm | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 39bcffd516..b92b6955a4 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -2382,8 +2382,10 @@ (define terminal-string-width
string-length))) ;using a statically-linked Guile
(define openpty
- (let ((proc (syscall->procedure int "openpty" '(* * * * *)
- #:library "libutil")))
+ (let ((proc (if musl-libc?
+ (syscall->procedure int "openpty" '(* * * * *)
+ #:library "libutil")
+ (syscall->procedure int "openpty" '(* * * * *)))))
(lambda ()
"Return two file descriptors: one for the pseudo-terminal control side,
and one for the controlled side."
@@ -2404,8 +2406,10 @@ (define openpty
(values (* head) (* inferior)))))))
(define login-tty
- (let* ((proc (syscall->procedure int "login_tty" (list int)
- #:library "libutil")))
+ (let* ((proc (if musl-libc?
+ (syscall->procedure int "login_tty" (list int)
+ #:library "libutil")
+ (syscall->procedure int "login_tty" (list int)))))
(lambda (fd)
"Make FD the controlling terminal of the current process (with the
TIOCSCTTY ioctl), redirect standard input, standard output and standard error
base-commit: 01d4363168ed10ea223047f7a7b83201f161ec0b
Information forwarded
to
guix-patches <at> gnu.org
:
bug#72395
; Package
guix-patches
.
(Thu, 01 Aug 2024 16:05:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 72395 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
soeren <at> soeren-tempel.net writes:
> From: Sören Tempel <soeren <at> soeren-tempel.net>
>
> Contrary to glibc, musl does not define the openpty and login-tty
> function in libutil.so. In fact, libutil.so does not exist on musl-based
> Linux distributions. Therefore, on musl-based systems we don't have
> to pass any #:library keyword argument to syscall->procedure.
> ---
> guix/build/syscalls.scm | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
> index 39bcffd516..b92b6955a4 100644
> --- a/guix/build/syscalls.scm
> +++ b/guix/build/syscalls.scm
> @@ -2382,8 +2382,10 @@ (define terminal-string-width
> string-length))) ;using a statically-linked Guile
>
> (define openpty
> - (let ((proc (syscall->procedure int "openpty" '(* * * * *)
> - #:library "libutil")))
> + (let ((proc (if musl-libc?
> + (syscall->procedure int "openpty" '(* * * * *)
> + #:library "libutil")
> + (syscall->procedure int "openpty" '(* * * * *)))))
> (lambda ()
> "Return two file descriptors: one for the pseudo-terminal control side,
> and one for the controlled side."
> @@ -2404,8 +2406,10 @@ (define openpty
> (values (* head) (* inferior)))))))
>
> (define login-tty
> - (let* ((proc (syscall->procedure int "login_tty" (list int)
> - #:library "libutil")))
> + (let* ((proc (if musl-libc?
> + (syscall->procedure int "login_tty" (list int)
> + #:library "libutil")
> + (syscall->procedure int "login_tty" (list int)))))
> (lambda (fd)
> "Make FD the controlling terminal of the current process (with the
> TIOCSCTTY ioctl), redirect standard input, standard output and standard error
>
> base-commit: 01d4363168ed10ea223047f7a7b83201f161ec0b
see syscall->procedure definition:
```
(define* (syscall->procedure return-type name argument-types
#:key library)
"Return a procedure that wraps the C function NAME using the dynamic FFI,
and that returns two values: NAME's return value, and errno. When LIBRARY is
specified, look up NAME in that library rather than in the global symbol name
space.
If an error occurs while creating the binding, defer the error report until
the returned procedure is called."
(catch #t
(lambda ()
;; Note: When #:library is set, try it first and fall back to libc
;; proper. This is because libraries like libutil.so have been subsumed
;; by libc.so with glibc >= 2.34.
(let ((ptr (dynamic-func name
(if library
(or (false-if-exception
(dynamic-link library))
(dynamic-link))
(dynamic-link)))))
;; The #:return-errno? facility was introduced in Guile 2.0.12.
(pointer->procedure return-type ptr argument-types
#:return-errno? #t)))
(lambda args
(lambda _
(throw 'system-error name "~A" (list (strerror ENOSYS))
(list ENOSYS))))))
```
In my understanding, when we can't find libutil, will try to find it in
libc. Do you have any problems using it?
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#72395
; Package
guix-patches
.
(Sat, 03 Aug 2024 10:40:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 72395 <at> debbugs.gnu.org (full text, mbox):
Hi!
Z572 <zhengjunjie <at> iscas.ac.cn> wrote:
> In my understanding, when we can't find libutil, will try to find it in
> libc. Do you have any problems using it?
Yea, for example consider the invocation `guix import pypi cart`.
Without this patch, this emits the following error message for me
on Alpine Linux Edge (a musl-based Linux distribution):
guix import: error: no source release for pypi package cart 1.2.2
hint: Backtrace:
In ice-9/boot-9.scm:
1685:16 19 (raise-exception _ #:continuable? _)
In guix/ui.scm:
867:16 18 (_ _)
340:43 17 (display-hint "This indicates that the\npackage is a…" . #)
In ice-9/boot-9.scm:
1747:15 16 (with-exception-handler #<procedure 7f8c8f9b2660 at ic…> …)
3474:28 15 (_)
3327:17 14 (resolve-interface (guix build syscalls) #:select _ # _ …)
In ice-9/threads.scm:
390:8 13 (_ _)
In ice-9/boot-9.scm:
3253:13 12 (_)
In ice-9/threads.scm:
390:8 11 (_ _)
In ice-9/boot-9.scm:
3544:20 10 (_)
2836:4 9 (save-module-excursion #<procedure 7f8c8f9b2600 at ice-…>)
3564:26 8 (_)
In unknown file:
7 (primitive-load-path "guix/build/syscalls" #<procedure …>)
In guix/build/syscalls.scm:
2385:14 6 (_)
In ice-9/boot-9.scm:
1747:15 5 (with-exception-handler #<procedure 7f8c8fa3b270 at ic…> …)
In guix/build/syscalls.scm:
456:39 4 (_)
In ice-9/boot-9.scm:
1747:15 3 (with-exception-handler #<procedure 7f8c8fa3b240 at ic…> …)
In unknown file:
2 (dynamic-link "libutil")
In system/foreign-library.scm:
190:25 1 (load-foreign-library _ #:extensions _ # _ #:search-path …)
In unknown file:
0 (dlopen "libutil.so" 1)
ERROR: In procedure dlopen:
In procedure dlopen: file "libutil.so", message "libutil.so: cannot open shared object file: No such file or directory"
With this patch applied, I instead get:
guix import: error: no source release for pypi package cart 1.2.2
hint: This indicates that the package is available on PyPI, but only as a "wheel" containing
binaries, not source. To build it from source, refer to the upstream repository at
`https://github.com/CybercentreCanada/cart'.
I assume the fallback code in syscall->procedure does not work correctly
then and the "correct fix" would be to fix this fallback code?
Greetings,
Sören
This bug report was last modified 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.