[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Defining a toolchain with musl libc

From: David Arroyo
Subject: Re: Defining a toolchain with musl libc
Date: Mon, 09 May 2022 19:54:13 -0400
User-agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27

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

        $ 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@' to 

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:

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

        -dynamic-linker /lib/ -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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]