Bug#1061370: gcc-14 ftbfs on armel
Control: tags -1 patch On 2024-01-29 10:23, Emanuele Rocca wrote: > Upstream proposed two patches though, the one I tried is: > > libatomic_la_LIBADD += $(addsuffix _8_2_.lo,$(SIZEOBJS)) > +libatomic_la_LIBADD += tas_1_2_.lo The problem was not the patch, but the fact that it did not include an updated Makefile.in. I updated it with the following command from within src/libatomic: AUTOM4TE=/usr/bin/autom4te2.69 autoreconf And added both Makefile.am and Makefile.in to the patch, see attached debdiff. With these changes, libat_test_and_set_1_i2 is not anymore listed among the undefined symbols in the output of objdump -T, and systemd builds fine. I haven't tried to re-enable ada and gccgo, but they should hopefully build again now too. diff -Nru gcc-14-14-20240127/debian/changelog gcc-14-14-20240127/debian/changelog --- gcc-14-14-20240127/debian/changelog 2024-01-27 09:51:04.0 +0100 +++ gcc-14-14-20240127/debian/changelog 2024-01-29 19:55:54.0 +0100 @@ -1,3 +1,9 @@ +gcc-14 (14-20240127-1.1) unstable; urgency=medium + + * Add upstream patch libatomic-armel.diff. Closes: #1061370. + + -- Emanuele Rocca Mon, 29 Jan 2024 19:55:54 +0100 + gcc-14 (14-20240127-1) unstable; urgency=medium * Snapshot, taken from the trunk 20240127. diff -Nru gcc-14-14-20240127/debian/patches/libatomic-armel.diff gcc-14-14-20240127/debian/patches/libatomic-armel.diff --- gcc-14-14-20240127/debian/patches/libatomic-armel.diff 1970-01-01 01:00:00.0 +0100 +++ gcc-14-14-20240127/debian/patches/libatomic-armel.diff 2024-01-29 19:55:54.0 +0100 @@ -0,0 +1,209 @@ +Index: gcc-14-14-20240127/src/libatomic/Makefile.am +=== +--- gcc-14-14-20240127.orig/src/libatomic/Makefile.am gcc-14-14-20240127/src/libatomic/Makefile.am +@@ -139,6 +139,7 @@ if ARCH_ARM_LINUX + IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64 + libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS))) + libatomic_la_LIBADD += $(addsuffix _8_2_.lo,$(SIZEOBJS)) ++libatomic_la_LIBADD += tas_1_2_.lo + endif + if ARCH_I386 + IFUNC_OPTIONS = -march=i586 +Index: gcc-14-14-20240127/src/libatomic/Makefile.in +=== +--- gcc-14-14-20240127.orig/src/libatomic/Makefile.in gcc-14-14-20240127/src/libatomic/Makefile.in +@@ -1,7 +1,7 @@ +-# Makefile.in generated by automake 1.15.1 from Makefile.am. ++# Makefile.in generated by automake 1.16.5 from Makefile.am. + # @configure_input@ + +-# Copyright (C) 1994-2017 Free Software Foundation, Inc. ++# Copyright (C) 1994-2021 Free Software Foundation, Inc. + + # This Makefile.in is free software; the Free Software Foundation + # gives unlimited permission to copy and/or distribute it, +@@ -95,7 +95,8 @@ target_triplet = @target@ + @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ s,$(SIZES),$(addsuffix \ + @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ _$(s)_1_.lo,$(SIZEOBJS))) \ + @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ $(addsuffix \ +-@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ _8_2_.lo,$(SIZEOBJS)) ++@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ _8_2_.lo,$(SIZEOBJS)) \ ++@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ tas_1_2_.lo + @ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@am__append_4 = $(addsuffix _8_1_.lo,$(SIZEOBJS)) + @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@am__append_5 = $(addsuffix _16_1_.lo,$(SIZEOBJS)) \ + @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@ $(addsuffix _16_2_.lo,$(SIZEOBJS)) +@@ -187,11 +188,16 @@ am__v_at_ = $(am__v_at_@AM_DEFAULT_V@) + am__v_at_0 = @ + am__v_at_1 = + depcomp = $(SHELL) $(top_srcdir)/../depcomp +-am__depfiles_maybe = depfiles ++am__maybe_remake_depfiles = depfiles ++am__depfiles_remade = ./$(DEPDIR)/atomic_16.Plo ./$(DEPDIR)/fence.Plo \ ++ ./$(DEPDIR)/fenv.Plo ./$(DEPDIR)/flag.Plo ./$(DEPDIR)/gcas.Plo \ ++ ./$(DEPDIR)/gexch.Plo ./$(DEPDIR)/glfree.Plo \ ++ ./$(DEPDIR)/gload.Plo ./$(DEPDIR)/gstore.Plo \ ++ ./$(DEPDIR)/init.Plo ./$(DEPDIR)/lock.Plo + am__mv = mv -f + CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ + $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS) +-LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \ ++LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \ + $(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \ + $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ + $(AM_CCASFLAGS) $(CCASFLAGS) +@@ -240,8 +246,8 @@ am__recursive_targets = \ + $(am__extra_recursive_targets) + AM_RECURSIVE_TARGETS = $(am__recursive_targets:-recursive=) TAGS CTAGS \ + cscope +-am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) \ +- $(LISP)auto-config.h.in ++am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP) \ ++ auto-config.h.in + # Read a list of newline-separated strings from the standard input, + # and print each of them once, without duplicates. Input order is + # *not* preserved. +@@ -258,9 +264,6 @@ am__define_uniq_tagged_files = \ + unique=`for i in $$list; do \ + if
Bug#1061370: gcc-14 ftbfs on armel
On 2024-01-29 09:04, Luca Boccassi wrote: > Guess that doesn't solve it them, as it's the same problem, the meson > build tests are failing, all of these should be 'YES': Upstream proposed two patches though, the one I tried is: libatomic_la_LIBADD += $(addsuffix _8_2_.lo,$(SIZEOBJS)) +libatomic_la_LIBADD += tas_1_2_.lo An earlier patch looked like this instead: libatomic_la_LIBADD += $(addsuffix _8_2_.lo,$(SIZEOBJS)) +libatomic_la_LIBADD += $(addsuffix _1_2_.lo,$(SIZEOBJS)) Trying the latter now. Note that this issue is making loads of packages fail, not just systemd.
Bug#1061370: gcc-14 ftbfs on armel
On Mon, 29 Jan 2024 at 20:36, Emanuele Rocca wrote: > > On 2024-01-29 01:33, Luca Boccassi wrote: > > On the Bugzilla report a patch has been linked, would it be possible to > > backport it, please? > > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644147.html > > I have rebuilt gcc-14 with the attached debdiff, and then tried building > systemd passing the newly built debs as --extra-package - which resulted > in libatomic1 and a few others being upgraded. Unfortunately systemd > still failed building, see full logs at: > https://people.debian.org/~ema/systemd_255.3-1_armel.build Guess that doesn't solve it them, as it's the same problem, the meson build tests are failing, all of these should be 'YES': Run-time dependency libcryptsetup found: YES 2.6.1 Checking for function "crypt_set_metadata_size" with dependency libcryptsetup: NO Checking for function "crypt_activate_by_signed_key" with dependency libcryptsetup: NO Checking for function "crypt_token_max" with dependency libcryptsetup: NO Checking for function "crypt_reencrypt_init_by_passphrase" with dependency libcryptsetup: NO Checking for function "crypt_reencrypt" with dependency libcryptsetup: NO Checking for function "crypt_set_data_offset" with dependency libcryptsetup: NO Checking for function "crypt_activate_by_token_pin" with dependency libcryptsetup: NO
Bug#1061370: gcc-14 ftbfs on armel
On 2024-01-29 01:33, Luca Boccassi wrote: > On the Bugzilla report a patch has been linked, would it be possible to > backport it, please? > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644147.html I have rebuilt gcc-14 with the attached debdiff, and then tried building systemd passing the newly built debs as --extra-package - which resulted in libatomic1 and a few others being upgraded. Unfortunately systemd still failed building, see full logs at: https://people.debian.org/~ema/systemd_255.3-1_armel.build diff -Nru gcc-14-14-20240127/debian/changelog gcc-14-14-20240127/debian/changelog --- gcc-14-14-20240127/debian/changelog 2024-01-27 09:51:04.0 +0100 +++ gcc-14-14-20240127/debian/changelog 2024-01-29 19:55:54.0 +0100 @@ -1,3 +1,9 @@ +gcc-14 (14-20240127-1.1) unstable; urgency=medium + + * Add upstream patch libatomic-armel.diff. + + -- Emanuele Rocca Mon, 29 Jan 2024 19:55:54 +0100 + gcc-14 (14-20240127-1) unstable; urgency=medium * Snapshot, taken from the trunk 20240127. diff -Nru gcc-14-14-20240127/debian/patches/libatomic-armel.diff gcc-14-14-20240127/debian/patches/libatomic-armel.diff --- gcc-14-14-20240127/debian/patches/libatomic-armel.diff 1970-01-01 01:00:00.0 +0100 +++ gcc-14-14-20240127/debian/patches/libatomic-armel.diff 2024-01-29 19:55:54.0 +0100 @@ -0,0 +1,12 @@ +Index: gcc-14-14-20240127/src/libatomic/Makefile.am +=== +--- gcc-14-14-20240127.orig/src/libatomic/Makefile.am gcc-14-14-20240127/src/libatomic/Makefile.am +@@ -139,6 +139,7 @@ if ARCH_ARM_LINUX + IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64 + libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS))) + libatomic_la_LIBADD += $(addsuffix _8_2_.lo,$(SIZEOBJS)) ++libatomic_la_LIBADD += tas_1_2_.lo + endif + if ARCH_I386 + IFUNC_OPTIONS = -march=i586 diff -Nru gcc-14-14-20240127/debian/rules.patch gcc-14-14-20240127/debian/rules.patch --- gcc-14-14-20240127/debian/rules.patch 2024-01-26 12:31:20.0 +0100 +++ gcc-14-14-20240127/debian/rules.patch 2024-01-29 19:55:54.0 +0100 @@ -232,6 +232,7 @@ endif debian_patches += go-testsuite +debian_patches += libatomic-armel # don't remove, this is regularly overwritten, see PR sanitizer/63958. #debian_patches += libasan-sparc
Bug#1061370: gcc-14 ftbfs on armel
On Mon, 29 Jan 2024 at 16:38, Emanuele Rocca wrote: > > Hi Luca, > > On 2024-01-29 01:33, Luca Boccassi wrote: > > This causes systemd to FTBFS on armel since the new upload of > > libatomic-14. No other architecture is affected. > > > > cc -o systemd-cryptsetup > > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-keyfile.c.o > > systemd-cryptsetup.p/src_cryptsetup_cryptsetup.c.o > > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-pkcs11.c.o > > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-tpm2.c.o -Wl,--as-needed > > -Wl,--no-undefined -fstack-protector > > '-Wl,-rpath,$ORIGIN/src/shared:' > > -Wl,-rpath-link,/home/bluca/systemd/foo/src/shared -Wl,--start-group > > src/shared/libsystemd-shared-255.so /lib/arm-linux-gnueabi/libcryptsetup.so > > /usr/lib/arm-linux-gnueabi/libssl.so > > /usr/lib/arm-linux-gnueabi/libcrypto.so -Wl,--end-group > > -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common > > /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to > > `libat_test_and_set_1_i2' > > collect2: error: ld returned 1 exit status > > From the build logs at [1] it seems that a mix of GCC 13 and 14 packages > was used, is this expected? > > Toolchain package versions: binutils_2.41.90.20240122-1 dpkg-dev_1.22.4 > g++-13_13.2.0-10 gcc-13_13.2.0-10 libc6-dev_2.37-14 > libstdc++-13-dev_13.2.0-10 libstdc++6_14-20240127-1 linux-libc-dev_6.6.13-1 > > [1] > https://buildd.debian.org/status/fetch.php?pkg=systemd=armel=255.3-2=1706528229=0 The package name is 'libatomic1' and it's not versioned after the GCC major version like the rest, so it seems to be all working as intended.
Bug#1061370: gcc-14 ftbfs on armel
Hi Luca, On 2024-01-29 01:33, Luca Boccassi wrote: > This causes systemd to FTBFS on armel since the new upload of > libatomic-14. No other architecture is affected. > > cc -o systemd-cryptsetup > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-keyfile.c.o > systemd-cryptsetup.p/src_cryptsetup_cryptsetup.c.o > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-pkcs11.c.o > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-tpm2.c.o -Wl,--as-needed > -Wl,--no-undefined -fstack-protector > '-Wl,-rpath,$ORIGIN/src/shared:' > -Wl,-rpath-link,/home/bluca/systemd/foo/src/shared -Wl,--start-group > src/shared/libsystemd-shared-255.so /lib/arm-linux-gnueabi/libcryptsetup.so > /usr/lib/arm-linux-gnueabi/libssl.so /usr/lib/arm-linux-gnueabi/libcrypto.so > -Wl,--end-group -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common > /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to > `libat_test_and_set_1_i2' > collect2: error: ld returned 1 exit status >From the build logs at [1] it seems that a mix of GCC 13 and 14 packages was used, is this expected? Toolchain package versions: binutils_2.41.90.20240122-1 dpkg-dev_1.22.4 g++-13_13.2.0-10 gcc-13_13.2.0-10 libc6-dev_2.37-14 libstdc++-13-dev_13.2.0-10 libstdc++6_14-20240127-1 linux-libc-dev_6.6.13-1 [1] https://buildd.debian.org/status/fetch.php?pkg=systemd=armel=255.3-2=1706528229=0
Bug#1061370: gcc-14 ftbfs on armel
Control: affects -1 systemd On Fri, 26 Jan 2024 20:10:40 +0100 Matthias Klose wrote: > On 24.01.24 09:58, Emanuele Rocca wrote: > > Hi Matthias, > > > > On 2024-01-23 09:01, Matthias Klose wrote: > >> This is a long standing, re-occurring issue which never has been > >> forwarded and committed by the armel ports to GCC upstream. > > > > You seem to be aware of previous occurrences of this issue. Please share > > the details you have available such as bug numbers, commits, and so > > forth. > > > > More in general though there have been several important issues with > > armel lately, not least the fact that there is very little hardware > > still supported by the kernel (essentially just the Raspberry Pi Zero > > and 1 AIUI [0]). It seems to me that the time has come to seriously > > consider whether supporting armel as an official port still makes sense. > > > > [0] https://salsa.debian.org/kernel-team/linux/-/commit/b53e2d881063b060934bee3da9378da3b5b5387b > > > > disabled ada, now ftbs with go. > > if you care about the Pi Zero, then please get involved upstream. > Listening to ARM guys, armv5t doesn't seem to raise any interest these days. > > Also having LLVM build failures, still targeting armv4t didn't raise any > attention to the Debian armel porters. > > So let's just say there is no man power to address issues, and probably > also lack of interest. This causes systemd to FTBFS on armel since the new upload of libatomic-14. No other architecture is affected. cc -o systemd-cryptsetup systemd-cryptsetup.p/src_cryptsetup_cryptsetup-keyfile.c.o systemd-cryptsetup.p/src_cryptsetup_cryptsetup.c.o systemd-cryptsetup.p/src_cryptsetup_cryptsetup-pkcs11.c.o systemd-cryptsetup.p/src_cryptsetup_cryptsetup-tpm2.c.o -Wl,--as-needed -Wl,--no-undefined -fstack-protector '-Wl,-rpath,$ORIGIN/src/shared:' -Wl,-rpath-link,/home/bluca/systemd/foo/src/shared -Wl,--start-group src/shared/libsystemd-shared-255.so /lib/arm-linux-gnueabi/libcryptsetup.so /usr/lib/arm-linux-gnueabi/libssl.so /usr/lib/arm-linux-gnueabi/libcrypto.so -Wl,--end-group -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to `libat_test_and_set_1_i2' collect2: error: ld returned 1 exit status On the Bugzilla report a patch has been linked, would it be possible to backport it, please? https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644147.html -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1061370: gcc-14 ftbfs on armel
On 24.01.24 09:58, Emanuele Rocca wrote: Hi Matthias, On 2024-01-23 09:01, Matthias Klose wrote: This is a long standing, re-occurring issue which never has been forwarded and committed by the armel ports to GCC upstream. You seem to be aware of previous occurrences of this issue. Please share the details you have available such as bug numbers, commits, and so forth. More in general though there have been several important issues with armel lately, not least the fact that there is very little hardware still supported by the kernel (essentially just the Raspberry Pi Zero and 1 AIUI [0]). It seems to me that the time has come to seriously consider whether supporting armel as an official port still makes sense. [0] https://salsa.debian.org/kernel-team/linux/-/commit/b53e2d881063b060934bee3da9378da3b5b5387b disabled ada, now ftbs with go. if you care about the Pi Zero, then please get involved upstream. Listening to ARM guys, armv5t doesn't seem to raise any interest these days. Also having LLVM build failures, still targeting armv4t didn't raise any attention to the Debian armel porters. So let's just say there is no man power to address issues, and probably also lack of interest. Matthias
Bug#1061370: gcc-14 ftbfs on armel
Hi Matthias, On 2024-01-23 09:01, Matthias Klose wrote: > This is a long standing, re-occurring issue which never has been > forwarded and committed by the armel ports to GCC upstream. You seem to be aware of previous occurrences of this issue. Please share the details you have available such as bug numbers, commits, and so forth. More in general though there have been several important issues with armel lately, not least the fact that there is very little hardware still supported by the kernel (essentially just the Raspberry Pi Zero and 1 AIUI [0]). It seems to me that the time has come to seriously consider whether supporting armel as an official port still makes sense. [0] https://salsa.debian.org/kernel-team/linux/-/commit/b53e2d881063b060934bee3da9378da3b5b5387b
Bug#1061370: gcc-14 ftbfs on armel
On 23.01.24 15:56, Wookey wrote: On 2024-01-23 09:01 +0100, Matthias Klose wrote: Package: src:gcc-14 Version: 14-20240121-1 Severity: important Tags: sid trixie ftbfs X-Debbugs-CC: debian-...@lists.debian.org gcc-14 ftbfs on armel. This is a long standing, re-occurring issue which never has been forwarded and committed by the armel ports to GCC upstream. Please do it. Why do you want the armel porters to forward this bug upstream, when forwarding bugs upstream is normally the package maintainers job? I mean sure someone could do that, but it's probably not been done so far becuase they thought you would. Is your point that actually it's not just a matter of formwarding - some armel-specific investigation is needed first to work out what's actually wrong? it's porters work to keep the basic toolchains working in Debian. This is not done by the armel porters. I'm not doing this work. If you want to keep this port alive, please spend the time and resources to do so.
Bug#1061370: gcc-14 ftbfs on armel
On 2024-01-23 09:01 +0100, Matthias Klose wrote: > Package: src:gcc-14 > Version: 14-20240121-1 > Severity: important > Tags: sid trixie ftbfs > X-Debbugs-CC: debian-...@lists.debian.org > > gcc-14 ftbfs on armel. This is a long standing, re-occurring issue which > never has been forwarded and committed by the armel ports to GCC upstream. > Please do it. Why do you want the armel porters to forward this bug upstream, when forwarding bugs upstream is normally the package maintainers job? I mean sure someone could do that, but it's probably not been done so far becuase they thought you would. Is your point that actually it's not just a matter of formwarding - some armel-specific investigation is needed first to work out what's actually wrong? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1061370: gcc-14 ftbfs on armel
Package: src:gcc-14 Version: 14-20240121-1 Severity: important Tags: sid trixie ftbfs X-Debbugs-CC: debian-...@lists.debian.org gcc-14 ftbfs on armel. This is a long standing, re-occurring issue which never has been forwarded and committed by the armel ports to GCC upstream. Please do it. [...] /usr/bin/ld: /<>/build/arm-linux-gnueabi/libatom ic/.libs/libatomic.so.1: undefined reference to `libat_test_and_set_1_i2' collect2: error: ld returned 1 exit status arm-linux-gnueabi-gnatlink-13: error when calling /usr/bin/arm-linux-gnueabi-gcc-13 gnatmake: *** link failed. make[5]: *** [gcc-interface/Makefile:638: bldtools/oscons/xoscons] Error 4 make[5]: Leaving directory '/<>/build/gcc/ada' make[4]: *** [Makefile:117: osconstool] Error 2
