#1131165 gcc-15 FTBFS for musl-linux-amd64

Package:
src:gcc-15
Source:
src:gcc-15
Submitter:
Helmut Grohne
Date:
2026-05-05 16:39:02 UTC
Severity:
normal
Tags:
#1131165#5
Date:
2026-03-12 18:09:34 UTC
From:
To:
Hi Matthias,

I attempted building gcc-15 for musl-linux-amd64. Doing so fails. The
immediate reason is that gcc defaults to enabling multilib for the
x86_64 (and other) CPUs and Debian's musl package does not build a i386
multilib package (and other combinations). Hence the gcc build ends up
missing C library parts and fails. I argue that enabling multilib on any
but the existing combinations in release architectures is not useful.
The gcc packaging actually does not consider any of the musl
architectures to be multilib and $(biarch32) is not "yes" in a build.
However, the architecture matching in rules2 does not cover musl and
therefore --disable-multilib is not passed to configure. I suggest
updating the architecture match to match by CPU rather than full
architecture as that's how gcc upstream determines the default for
multilib. I'm attaching a patch implementing this.

Helmut

#1131165#10
Date:
2026-04-28 07:54:38 UTC
From:
To:
Is there any documentation for musl, which triplets and/or multiarch
identifiers are used for these musl packages?

#1131165#15
Date:
2026-04-28 11:14:59 UTC
From:
To:
Hi Matthias,

I don't think so.

Generally, you can turn most of any-gnu-linux-any architectures into
musl architectures by prepending "musl-linux-" to the Debian
architecture name. When it comes to the GNU triplet, the typical Debian
architecture looks like CPU-linux-gnuABI. When you move from glibc to
musl, that becomes CPU-linux-muslABI. The multiarch tuple works the way.
Examples:

glibc                        | musl
Debian | GNU                 | Debian           | GNU
amd64  | x86_64-linux-gnu    | musl-linux-amd64 | x86_64-linux-musl
i386   | i686-linux-gnu      | musl-linux-i386  | i686-linux-musl
armhf  | arm-linux-gnueabihf | musl-linux-armhf | arm-linux-musleabihf

For musl-linux-i386, the multiarch tuple becomes i386-linux-musl. For
everything else, there is no difference to the GNU triplet.

Helmut

#1131165#20
Date:
2026-05-01 08:59:46 UTC
From:
To:
please check if that works for you:
--- a/debian/rules.defs +++ b/debian/rules.defs @@ -2044,6 +2044,14 @@ ifeq ($(derivative),Ubuntu) else ifeq ($(derivative),Debian) biarchx32archs := /amd64/i386/ endif + +ifneq (,$(findstring musl, $(DEB_TARGET_GNU_TYPE))) + biarch32archs := + biarch64archs := + biarchn32archs := + biarchx32archs := +endif + $(foreach x,32 64 n32 x32,$(eval $(call gen_biarch,$(x)))) ifeq ($(DEB_TARGET_ARCH),sh4)
#1131165#25
Date:
2026-05-04 11:16:38 UTC
From:
To:
Hi Matthias,

Your proposed patch does not work for me. My build performs a multilib
configuration and that happens to fail. In particular, your patch does
not cause the --disable-multilib flag to be passed to configure.

I have two remarks. Your patch resets those variables /after/ they have
been used to populate e.g. ${biarch32} (lines 1886 to 1895) as your hunk
comes later (lines 2044 and later). This is further contrieved by the
fact that even current rules.defs modifies biarch32archs and friends
(around line 2019) after they have been used for matching (see above).

I find the use of findstring with DEB_TARGET_GNU_TYPE unfortunate. Such
matching has bitten us earlier (e.g. with the "arc" architecture).
Please use something like "ifneq (musl,$(DEB_TARGET_ARCH_LIBC))"
instead.

Helmut