Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Feb 2024 02:14:11 +0000 (UTC)
From: Thorsten Glaser <>
Subject: Re: musl-gcc: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc:
 unrecognised command-line option '-EL'

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

%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} %(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:

%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} %(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

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 ;-)

„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.”)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.