[PATCH] syscalls: Support musl libc in openpty and login-tty

  • Open
  • quality assurance status badge
Details
2 participants
  • soeren
  • Z572
Owner
unassigned
Submitted by
soeren
Severity
normal
S
S
soeren wrote on 31 Jul 11:41 +0200
(address . guix-patches@gnu.org)
ecdbe1915ce12e411816a7da2b59d48a6619630d.1722418917.git.soeren@soeren-tempel.net
From: Sören Tempel <soeren@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(-)

Toggle diff (32 lines)
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
Z
Z
Z572 wrote on 1 Aug 18:03 +0200
(address . soeren@soeren-tempel.net)
87h6c4w7qm.fsf@iscas.ac.cn
soeren@soeren-tempel.net writes:

Toggle quote (43 lines)
> From: Sören Tempel <soeren@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?
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAmarsdEACgkQO1qpk+Gi
3/CvHRAAoJgg6EQZg5bWbEgoMwm9Kk5pQX9AAlvNtDlrtr81SpzrLtdH6M8RNGdG
PluLjMHApbMVrBXowHS7aUdEc4yP+cX1J4Zo+90YxxrJigmCE+YWFS3fbTJxSBJ9
ZSfa6aPHSH8YcgcrUnHJEDhyOr/FRuArOq2NYZtVOz2jV2z/VEdWdM6HQ/2tiGPh
pRceK0IDS25Q6VqgzLHZtnLaNpVrzwciU1m4CHfAZs+aUsVT/IvxTJUlrbW23Jzz
SU0J1dr+Nltxw6r6Ogx3nu592bP8PHCpDPOJSnoGhWqOU3vAhDJ7MlBb9K4xsT4w
MHNxiQDWXOsl72LbhjHdu/2p/7f8w/lG9Q4KrL9o1STP2/smR2cn+cYgACUKua4e
M5Qgq/9vJNUPEFmckP6Y60NNIm2FODn93F+Ovs5DhZHWuz3sy3htM1yMPm5JU5sy
MBrBml18qkvoIfqOPQRb5tZKuU2Oo8Rgvt65QbobX9IX+zgEMcMsT4/TKsJ+q+W5
54rp94JaD8SdWTqCVIq4IXfvIuh29IaVv1qXXTxpAabXUD5xRaiDjLlZvBY0TM6E
TfxH5+Xd5pB6vDcnV7COfpe7UWZIVeBgwKWW/2jGP/Mgk7z74pwksIh5afBfqW9m
MfzPsQGHVCk8I4SdkwmrquU06uzEKf9Xh12zxgfXr3C5ZueZ//k=
=ySI7
-----END PGP SIGNATURE-----

S
S
Sören Tempel wrote on 3 Aug 12:38 +0200
(name . Z572)(address . zhengjunjie@iscas.ac.cn)
2LJ9T2UGSZRU4.2KSFZPMA47XMM@8pit.net
Hi!

Z572 <zhengjunjie@iscas.ac.cn> wrote:
Toggle quote (3 lines)
> 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

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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 72395@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 72395
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch