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