[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Defining a toolchain with musl libc
From: |
zimoun |
Subject: |
Re: Defining a toolchain with musl libc |
Date: |
Mon, 09 May 2022 19:09:34 +0200 |
Hi,
This sounds cool!
On Mon, 11 Apr 2022 at 22:34, "David Arroyo" <david@aqwari.net> wrote:
> $ 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.
Maybe “guix graph --path” could help. Well, maybe skalibs and/or
execline retain a reference to bash or bash-minimal which probably drags
glibc and gcc.
But that does not explain the “dynamically linked“ above.
> 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))
[...]
> (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:
[...]
> Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert
> narrow string to output locale" 84 #f #f)'.
> builder for
> `/gnu/store/vnysv6hbb8zwyy8jawy1ayd2nfv38l4y-gcc-musl-1.2.2-10.3.0.drv'
> failed with exit code 1
> build of
> /gnu/store/vnysv6hbb8zwyy8jawy1ayd2nfv38l4y-gcc-musl-1.2.2-10.3.0.drv failed
> View build log at
> '/var/log/guix/drvs/vn/ysv6hbb8zwyy8jawy1ayd2nfv38l4y-gcc-musl-1.2.2-10.3.0.drv.bz2'.
Well, I do not know if GCC needs some locales from Glibc to build. It
is rebuilt because,
--8<---------------cut here---------------start------------->8---
(define* (make-gcc-toolchain gcc
[...]
(let ((gcc (if libc (make-gcc-libc gcc libc) gcc))
--8<---------------cut here---------------end--------------->8---
where ’make-gcc-libc’ is defined in (gnu packages base). Therefore, it
is probably not straightforward to use ’make-gcc-toolchain’ with musl as
libc.
Note that usually musl comes from a wrapper around gcc, named
’musl-gcc’. It is specifically disabled by the musl package:
#:configure-flags
(list "--disable-gcc-wrapper")))
I do not know why. Maybe because at the time of commit
ce728f70e5ef8783a28652e382c2c9f61c7b4c06, it was not necessary or maybe
because the license of musl is incompatible with the one of GCC.
Well, I would take this path: rebuild a variant of musl with the wrapper
and try to make a C toolchain using this wrapper.
Maybe the package musl-cross could be interesting.
Cheers,
simon
- Re: Defining a toolchain with musl libc,
zimoun <=