From: Thorsten Glaser <tg@mirbsd.de>
To: musl@lists.openwall.com
Subject: Re: [musl] musl-gcc: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
Date: Sun, 4 Feb 2024 02:14:11 +0000 (UTC) [thread overview]
Message-ID: <Pine.BSM.4.64L.2402040112580.23552@herc.mirbsd.org> (raw)
In-Reply-To: <20240203193217.GW4163@brightrain.aerifal.cx>
Rich Felker dixit:
>OK, it's not musl that's unusable
That referred to the Debian package musl-tools originally.
>, but the gcc wrapper. This is not
>the recommended way to use musl except as minimal evaluation setup or
>for compiling very simple programs
Huh? Where does it say that, and how else is one supposed to do this?
I have been building and testing mksh with the diet, klcc and musl-gcc
wrappers on all Debian architectures they are available for years, and
this is the first time I remember running into problems with it.
>, and as you've found, it seems it's
>almost entirely untested except on a couple mainstream archs.
>
>This is something we should fix
That would be welcome, thanks.
>1. On some archs, which I think includes mips, it can work in
> principle, but has gratuitous bugs keeping it from working. These
> should be easy to fix.
I’m testing those semi-automatically for all arches in Debian that
have a musl-tools package. That is currently:
release arches: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x
ports arches: m68k sh4
removed arches: mips mipsel
>2. On some archs such as powerpc, the ABI is almost surely mismatched
> with the existing toolchain on a non-musl system. This should be
> caught at configure time, since the existing gcc is not able to
> build musl anyway
Ah, this may be the reason we have no musl on powerpc in Debian.
> , but it's possible that with sufficient additions
> to CFLAGS/CC, it might be possible to get musl to build, but then
> have a broken wrapper still (or to compile, but fail at link time
> or produce a broken libc.so due to mismatched libgcc.a). This
> probably needs attention too.
This sounds to me like configure should take care of adding the
needed flags both to CFLAGS and the wrapper on powerpc?
>I'll try to take a look at this soon and see if the proposed wrapper
>fix seems right for the mips situation
At least for MIPS, it looks to me so. The original specs are:
Debian sid, gcc 13.2.0-13/mips64el:
*cc1:
%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} %(subtarget_cc1_spec)
*subtarget_cc1_spec:
%{!mandroid|tno-android-cc:%{profile:-p};:%{profile:-p} %{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}} %{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC}}}}}
We lost mipsel in unstable recently, but bookworm still has it
with gcc 12.2.0-14:
*cc1:
%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} %(subtarget_cc1_spec)
*subtarget_cc1_spec:
%{!mandroid|tno-android-cc:%{profile:-p};:%{profile:-p} %{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}} %{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC}}}}}
On amd64, cc1 does include the defaulting to PIC part:
[…] %{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC}}}}}
So maybe this does need specific looking at in general, to avoid
surprises.
One idea would be to output gcc -dumpspecs during the build, then
inspect various distros’ build logs for this to see whether something
from there needs to be added.
I think the MIPS problem is that -EL is added by the frontend by
default; were it not, or were it to add -mel instead, we wouldn’t
have this problem. So, unclean-ish solution on the GCC side. I do
wonder what changed between GCC 12 and 13 to trigger this, though.
>, but the wrapper is generally low-priority, and there's other stuff
>I'm trying to get to/finish first.
OK, fair. Maybe this can be applied in Debian, and until then, I’m
using a gcc-12 dependency on MIPS for mksh to build with musl-gcc,
I probably could do the same workaround by copying the specs to a
temporary directory, too…
If I can help in any way, e.g. by testing things on Debian project
machines (porterboxen), feel free to ping me (Cc, or on Fedi). I
also have connections to Debian porters for various ports arches
(well, that’s mostly cbmuser these days, though I helped out in
the past as well).
Something else relating to the wrapper: Debian #971937 indicates
that musl’s stdc-predef.h is not automatically included when using
it (but at least neither is glibc’s, so that is a plus compared to
diet (dietlibc wrapper).
────────────────────────────────────────────────────────────────────────
And (I know this has been a contended topic, but from an upstream
PoV, please let me squeeze in this), it would be good if there was
a __MUSL__ predef not because musl needs special handling, but to
not do all the special handling I have to do to get things working
on all the other libcs for Linux (dietlibc, klibc, µClibc, glibc in
modern and ancient versions, and even libc5). If I knew it was musl
I could just skip a whole block of tests and workarounds. It *has*
been the most pleasant Linux libc to work with, and so far the only
one I have not had to contribute bugfixes to yet ;-)
Thanks,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
next prev parent reply other threads:[~2024-02-04 2:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-03 8:20 [musl] musl: " Thorsten Glaser
2024-02-03 8:37 ` Thorsten Glaser
2024-02-03 19:32 ` Rich Felker
2024-02-04 2:14 ` Thorsten Glaser [this message]
2024-02-04 20:04 ` [musl] musl-gcc: " Markus Wichmann
2024-02-05 10:16 ` Thorsten Glaser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.BSM.4.64L.2402040112580.23552@herc.mirbsd.org \
--to=tg@mirbsd.de \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).