Re: Defining a toolchain with musl libc

["David Arroyo" <david@aqwari.net>]

Hi Simon, thanks for your reply!

I must confess that I started this thread with an XY problem; my problem was with execline binaries segfaulting after I performed a pivot_root operation. I don't fully recall why, but I suspected the segfault occurred  when execv() tried to load and/or use a dynamic library. I was trying to verify this theory by statically linking execline and trying to reproduce the crash.

But since then there some updates to the glibc package and I cannot reproduce the issue anymore. I could try to go back with the time-machine and reproduce again but it's not urgent for me anymore.

On Mon, May 9, 2022, at 13:09, zimoun wrote:
> On Mon, 11 Apr 2022 at 22:34, "David Arroyo" <david@aqwari.net> wrote:
> 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.

That is a nifty tool, I didn't know about the `--path` option. Unfortunately it didn't seem to work here, I tried the following from the root of my channel repo:

	$ guix graph --path --type=bag-emerged -L $(pwd) -e '(@ (aqwari packages skaware) execline-musl-static)' glibc
	guix graph: error: no path from 'execline-musl-static@2.8.1.0' to 'glibc@2.33'

However, if I render the full `--type=bag-emerged` graph, massive as it is, glibc is clearly present and referenced by dozens of other nodes. There are too many edges for me to trace each one, but it looks like the path you predicted from execline -> bash-minimal -> glibc is there.

> 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.

Newer versions of GCC actually have an `-mmusl` flag and allow for target
triplets include `-musl-`, which appear to accomplish something similar. In fact, in a separate project this G-expression worked well for compiling a single C file with musl, statically:

https://git.sr.ht/~droyo/guix-channel/tree/640fe1b4eabe9a3aaa4b532c0ed71e7abb74dae8/item/aqwari/namespace.scm#L288-299

> Well, I would take this path: rebuild a variant of musl with the wrapper
> and try to make a C toolchain using this wrapper.

This sounds like a reasonable approach. The only potential issue I see is this option in mus-gcc's spec file:

	*link:
	-dynamic-linker /lib/ld-musl-x86_64.so.1 -nostdlib %{shared:-shared} %{static:-static} %{rdynamic:-export-dynamic}

but I'm not producing dynamically linked binaries anyway. While this is not urgent for me anymore, I'm still interested and I will probably try this in the next few weeks.

> Maybe the package musl-cross could be interesting.

I will take a look. Initially I was put off because that package hard-codes its own gcc, linux headers, and binutils versions rather than tracking the common packages. But it could be good inspiration.

Thanks again!
David