[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.BSM.4.64L.2402040112580.23552@herc.mirbsd.org>
Date: Sun, 4 Feb 2024 02:14:11 +0000 (UTC)
From: Thorsten Glaser <tg@...bsd.de>
To: musl@...ts.openwall.com
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 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.”)
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.
