From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 0780927EFA for ; Sat, 3 Feb 2024 20:32:16 +0100 (CET) Received: (qmail 23940 invoked by uid 550); 3 Feb 2024 19:29:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23908 invoked from network); 3 Feb 2024 19:29:39 -0000 Date: Sat, 3 Feb 2024 14:32:18 -0500 From: Rich Felker To: Thorsten Glaser Cc: 1050429@bugs.debian.org, Bastian Blank , musl@lists.openwall.com Message-ID: <20240203193217.GW4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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@eberlin:~$ 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@eberlin:~$ mips64el-linux-gnuabi64-gcc hello.c -specs ~/musl-gcc.specs > (sid_mips64el-dchroot)tg@eberlin:~$ ./a.out > hi > (sid_mips64el-dchroot)tg@eberlin:~$ 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