[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240203193217.GW4163@brightrain.aerifal.cx>
Date: Sat, 3 Feb 2024 14:32:18 -0500
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: 1050429@...s.debian.org, Bastian Blank <waldi@...ian.org>,
musl@...ts.openwall.com
Subject: Re: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc:
unrecognised command-line option '-EL'
On Sat, Feb 03, 2024 at 08:20:28AM +0000, Thorsten Glaser wrote:
> Hi musl maintainers,
>
> waldi indeed provided a fix for this bug forgot to Cc me, so I missed
> it until now. I tested this:
>
>
>
> (sid_mips64el-dchroot)tg@...rlin:~$ sh -x $(which musl-gcc) hello.c
> + exec mips64el-linux-gnuabi64-gcc hello.c -specs /usr/lib/mips64el-linux-musl/musl-gcc.specs
> mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
> (sid_mips64el-dchroot)tg@...rlin:~$ mips64el-linux-gnuabi64-gcc hello.c -specs ~/musl-gcc.specs
> (sid_mips64el-dchroot)tg@...rlin:~$ ./a.out
> hi
> (sid_mips64el-dchroot)tg@...rlin:~$ diff -u /usr/lib/mips64el-linux-musl/musl-gcc.specs musl-gcc.specs
> --- /usr/lib/mips64el-linux-musl/musl-gcc.specs 2023-11-10 19:30:40.000000000 +0000
> +++ musl-gcc.specs 2024-02-03 08:07:01.309465472 +0000
> @@ -1,10 +1,11 @@
> %rename cpp_options old_cpp_options
> +%rename cc1 old_cc1
>
> *cpp_options:
> -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s %(old_cpp_options)
>
> *cc1:
> -%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s
> +%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s %(old_cc1)
>
> *link_libgcc:
> -L/usr/lib/mips64el-linux-musl -L .%s
>
>
>
> This change (to tools/musl-gcc.specs.sh in the source tree) probably
> makes sense on all architectures, so perhaps do that even. Upstream
> should also consider including this and check which of the original
> specs need not be removed and can be kept like this.
>
> bye,
> //mirabilos
OK, it's not musl that's unusable, but the gcc wrapper. This is not
the recommended way to use musl except as minimal evaluation setup or
for compiling very simple programs, and as you've found, it seems it's
almost entirely untested except on a couple mainstream archs.
This is something we should fix, but there are two issues:
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.
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, 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.
I'll try to take a look at this soon and see if the proposed wrapper
fix seems right for the mips situation, but the wrapper is generally
low-priority, and there's other stuff I'm trying to get to/finish
first.
Rich
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.
