- Package:
- src:gcc-15
- Source:
- src:gcc-15
- Submitter:
- Helmut Grohne
- Date:
- 2026-05-05 16:39:02 UTC
- Severity:
- normal
- Tags:
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
Is there any documentation for musl, which triplets and/or multiarch identifiers are used for these musl packages?
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
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)
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