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 3581421123 for ; Sun, 4 Feb 2024 03:16:11 +0100 (CET) Received: (qmail 9942 invoked by uid 550); 4 Feb 2024 02:13:33 -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 9892 invoked from network); 4 Feb 2024 02:13:31 -0000 Date: Sun, 4 Feb 2024 02:14:11 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com In-Reply-To: <20240203193217.GW4163@brightrain.aerifal.cx> Message-ID: References: <20240203193217.GW4163@brightrain.aerifal.cx> Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [musl] 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=E2=80=99m 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}} %(su= btarget_cc1_spec) *subtarget_cc1_spec: %{!mandroid|tno-android-cc:%{profile:-p};:%{profile:-p} %{!mglibc:%{!muclib= c:%{!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}} %(su= btarget_cc1_spec) *subtarget_cc1_spec: %{!mandroid|tno-android-cc:%{profile:-p};:%{profile:-p} %{!mglibc:%{!muclib= c:%{!mbionic: -mbionic}}} %{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC}}}}} On amd64, cc1 does include the defaulting to PIC part: [=E2=80=A6] %{!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=E2=80=99 build logs for this to see whether somethi= ng 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=E2=80=99t 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=E2=80=99m 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=E2=80=A6 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=E2=80=99s mostly cbmuser these days, though I helped out in the past as well). Something else relating to the wrapper: Debian #971937 indicates that musl=E2=80=99s stdc-predef.h is not automatically included when using it (but at least neither is glibc=E2=80=99s, so that is a plus compared to diet (dietlibc wrapper). =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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, =C2=B5Clibc, 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 --=20 =E2=80=9ECool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.=E2=80=9C =09-- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: =E2=80=9C[=E2=80=A6]uhr.gz is a reason to install mksh on every system= =2E=E2=80=9D)