Re: Defining a toolchain with musl libc

[zimoun]

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