Hi, This sounds cool!
On Mon, 11 Apr 2022 at 22:34, "David Arroyo" <[email protected]> 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
