[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Defining a toolchain with musl libc
From: |
David Arroyo |
Subject: |
Defining a toolchain with musl libc |
Date: |
Mon, 11 Apr 2022 22:34:45 -0400 |
User-agent: |
Cyrus-JMAP/3.7.0-alpha0-386-g4174665229-fm-20220406.001-g41746652 |
Hello,
I want to rebuild the packages in the `skarnet` module to be statically
linked with musl libc. I don't mind if my C/C++ toolchain itself does
not use musl libc, so initially, I tried simply modifying the packages
and their direct dependencies, like so:
(define (compose . fns)
(let ((call (lambda (f x) (f x))))
(lambda (p) (fold-right call p fns))))
(define (static-link p)
(package/inherit p
(arguments
(substitute-keyword-arguments (package-arguments p)
((#:configure-flags flags ''())
`(cons* "LDFLAGS=-static" "--disable-shared" ,flags))))))
(define replace-glibc
(package-input-rewriting `((,glibc . ,musl)) #:deep? #t))
(define (append-name suffix)
(lambda (p)
(package/inherit p
(name (string-append p suffix)))))
(define package-with-musl
(package-mapping
(compose static-link replace-glibc) #:deep? #f))
(define hello-musl (package-with-musl hello))
(define execline-musl (package-with-musl execline))
Then I tested with
$ guix build -L /path/to/module -e '(@ (module path) hello-musl)'
This worked with simple packages like `hello`, but other packages
like `execline` still ended up with dynamically linked binaries:
$ out=$(guix build -L $(pwd) -e '(@ (aqwari packages skaware)
execline-musl)')
$ file $out/bin/fdmove
/gnu/store/82r5ilk3jir7cssmhc8bi87qqj46p29h-execline-2.8.1.0/bin/fdmove: ELF
64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.32, not stripped
$ guix gc --requisites $out
/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8
/gnu/store/hxxbjrm4iw6aj203zli6hj4ds1l27s3k-skalibs-2.11.0.0
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33
/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib
/gnu/store/82r5ilk3jir7cssmhc8bi87qqj46p29h-execline-2.8.1.0
I don't know how gcc and glibc ended up in there. I tried reading the
code, but I am not familiar enough with it to follow it yet. I think
they may get added as implicit inputs by gnu-build-system, and I might
not be using the package-input-rewriting transform correctly.
On my second try, I tried to create a GCC+musl toolchain and use that
I tried to create a toolchain like so:
(define my-toolchain (make-gcc-toolchain gcc musl))
But this failed with the error:
guix build: error: reference to invalid output 'static' of derivation
'/gnu/store/jmp8rccdwnrnl9x947xp7a75kmgdhylp-musl-1.2.2.drv'
This is because the musl package does not have a "static" output, which
the package builder in `make-gcc-toolchain` tries to access. To work
around that issue, I added empty outputs to the musl package:
(define musl-fix-outputs
(package
(inherit musl)
(outputs '("out" "static" "debug"))
(arguments
(list
#:phases
#~(modify-phases %standard-phases
(delete 'check)
(add-after 'build 'ensure-outputs
(lambda _
(mkdir-p #$output:static)
(mkdir-p #$output:debug))))))))
(define my-toolchain
(make-gcc-toolchain gcc musl-fix-outputs))
Then I tried to build the `hello` package:
(package-with-c-toolchain hello my-toolchain)
This rebuilds the musl package, and gets to the 'patch-source-shebangs
phase of the gcc rebuild, where it fails with the error:
error: in phase 'patch-source-shebangs': uncaught exception:
encoding-error "scm_to_stringn" "cannot convert narrow string to output
locale" 84 #f #f
I've attached the full error trace to this email. I am not sure what to
make of this error, or whether it is a red herring or not. Does anyone
see what I'm doing wrong? Or does anyone have an example of building a
non-trivial package against musl?
Thanks,
David
guix-build.log
Description: Text Data
- Defining a toolchain with musl libc,
David Arroyo <=