Created attachment 658524 [details] build.log build.log is from ppc but probably fails on any 32bit platform. [...] make[2]: Entering directory '/var/tmp/portage/dev-libs/apr-1.7.0-r1/work/apr-1.7.0/test' /bin/sh /var/tmp/portage/dev-libs/apr-1.7.0-r1/work/apr-1.7.0/libtool --silent --mode=compile powerpc-unknown-linux-gnu-gcc -pthread -Os -mcpu=7450 -pipe -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I../include -I./../include -o globalmutexchild.lo -c globalmutexchild.c && touch globalmutexchild.lo /bin/sh /var/tmp/portage/dev-libs/apr-1.7.0-r1/work/apr-1.7.0/libtool --silent --mode=link powerpc-unknown-linux-gnu-gcc -pthread -Os -mcpu=7450 -pipe -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I../include -I./../include -no-install -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -o globalmutexchild globalmutexchild.lo ../libapr-1.la -luuid -lrt -lcrypt -lpthread -ldl /usr/lib/gcc/powerpc-unknown-linux-gnu/9.3.0/../../../../powerpc-unknown-linux-gnu/bin/ld: ../.libs/libapr-1.so: undefined reference to `__sync_val_compare_and_swap_8' /usr/lib/gcc/powerpc-unknown-linux-gnu/9.3.0/../../../../powerpc-unknown-linux-gnu/bin/ld: ../.libs/libapr-1.so: undefined reference to `__sync_fetch_and_sub_8' /usr/lib/gcc/powerpc-unknown-linux-gnu/9.3.0/../../../../powerpc-unknown-linux-gnu/bin/ld: ../.libs/libapr-1.so: undefined reference to `__sync_sub_and_fetch_8' /usr/lib/gcc/powerpc-unknown-linux-gnu/9.3.0/../../../../powerpc-unknown-linux-gnu/bin/ld: ../.libs/libapr-1.so: undefined reference to `__sync_fetch_and_add_8' /usr/lib/gcc/powerpc-unknown-linux-gnu/9.3.0/../../../../powerpc-unknown-linux-gnu/bin/ld: ../.libs/libapr-1.so: undefined reference to `__sync_lock_test_and_set_8' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:115: globalmutexchild] Error 1 make[2]: Leaving directory '/var/tmp/portage/dev-libs/apr-1.7.0-r1/work/apr-1.7.0/test'
Created attachment 658526 [details] emerge --info
Did you manage to build apache-tools and apache with the most recent apr? It fails for the same reason you quoted here (undefined reference to `__sync_fetch_and_sub_8') on both of my 32-bit ppc machines and blocks my system update.
Debian has https://sources.debian.org/patches/apr/1.7.0-6/generic-64bit-atomics.patch/ but doesn't look sufficient.
Ah, from Void Linux: https://github.com/void-linux/void-packages/blob/df7ebc36a9ffb208a0d60da58a98a2c4936b1735/srcpkgs/apr/patches/atomic64.patch
(In reply to Sam James from comment #3) > Debian has > https://sources.debian.org/patches/apr/1.7.0-6/generic-64bit-atomics.patch/ > but doesn't look sufficient. (Note that the Debian patch looks like it could work if we add in some arch defines)
*** Bug 764662 has been marked as a duplicate of this bug. ***
*** Bug 738642 has been marked as a duplicate of this bug. ***
*** Bug 778455 has been marked as a duplicate of this bug. ***
@Sam: I can canfirm that apr-1.6.3-r5, apr-1.6.5-r2 and apr-1.7.0-r2 from your PR build fine on ppc. Thanks!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8a3c82d2c1bac689e848c65dc0ad53e4cdd6fc7a commit 8a3c82d2c1bac689e848c65dc0ad53e4cdd6fc7a Author: Sam James <sam@gentoo.org> AuthorDate: 2021-05-09 07:16:06 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2021-05-11 08:44:37 +0000 dev-libs/apr: fix underlinking for atomics on ppc, sparc Fixes errors in the produced library like: > undefined reference to `__sync_val_compare_and_swap_8' Forcing linkage against libatomic didn't work. May be worth investigation in future but need to get ppc and sparc working again. Closes: https://bugs.gentoo.org/740464 Signed-off-by: Sam James <sam@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/20735 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> dev-libs/apr/{apr-1.6.3-r4.ebuild => apr-1.6.3-r5.ebuild} | 8 ++++++++ dev-libs/apr/{apr-1.6.5-r1.ebuild => apr-1.6.5-r2.ebuild} | 8 ++++++++ dev-libs/apr/{apr-1.7.0-r1.ebuild => apr-1.7.0-r2.ebuild} | 8 ++++++++ 3 files changed, 24 insertions(+)
(In reply to ernsteiswuerfel from comment #9) > @Sam: > I can canfirm that apr-1.6.3-r5, apr-1.6.5-r2 and apr-1.7.0-r2 from your PR > build fine on ppc. Thanks! Thank you for testing and thanks to Lars for merging!
https://bugs.gentoo.org/815265#c3 for mips
This is still an issue on 32 bit arm As to the workaround added to the ebuild for ppc and sparc, I'm not real sure what that does exactly but as I tried to find a generic solution for my manual fixes to www-servers/apache and what I thought to remember was dev-libs/apr (a misidentification: it was probably dev-libs/apr-util) I added ` -Wl,--as-needed -latomic` to the link line as defined in `configure.in`. This leads to an interesting result: normal build (and with enforced `--disable-nonportable-atomics`): -------------------------------------- # ldd ./.libs/libapr-1.so libuuid.so.1 => /lib/libuuid.so.1 (0xb6f0f000) libc.so.6 => /lib/libc.so.6 (0xb6d20000) /lib/ld-linux.so.3 (0xb6ee3000) -------------------------------------- patched build: -------------------------------------- # ldd /usr/lib/libapr-1.so libatomic.so.1 => //usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/12/libatomic.so.1 (0xb6f78000) libuuid.so.1 => /lib/libuuid.so.1 (0xb6f0d000) libc.so.6 => /lib/libc.so.6 (0xb6d80000) /lib/ld-linux.so.3 (0xb6f47000) -------------------------------------- So even though libapr builds successfully without being linked to libatomic, the linker still considers this linkage needed. With the latter version of libapr I can build apache without issues.
Created attachment 861089 [details, diff] Explicitly link to atomic "as needed"
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad634152ee4e5b0d5fa1002c2fa1dc0cd7755351 commit ad634152ee4e5b0d5fa1002c2fa1dc0cd7755351 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-09-23 15:58:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-23 15:59:53 +0000 dev-libs/apr: more robustly check for dodgy atomics Let's use append-atomic-libs, which is for this purpose, instead of hardcoding a brittle list of arches which isn't so accurate. Mariusz reported that armv6j at least suffered from this problem. Rather than shoving in 'use arm', let's just use the proper test. Bug: https://bugs.gentoo.org/740464 Tested-by: Mariusz Koniarz <mkoniarz@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> dev-libs/apr/apr-1.7.4-r1.ebuild | 150 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 150 insertions(+)
Huh, sorry Gordon, I'd missed your comment until now. Bit curious as to why the LDFLAGS in profiles (setting -Wl,--as-needed) don't take affect here though.
s/affect/effect/
Dig in memory... I believe the resulting link line contained a --no-as-needed that took precedence over everything settable in profile.
Thanks. I'm going to leave it for now given I can't spot that when grepping 1.7.4 (possible some patch fixed it in the interim).
The main point about my comment, though reading back maybe not explicitly clear, is that the failure to link to atomic is recurring over several packages. So even though the original fix that required a full list of affected platforms (which didn't include mine) allowed building of libapr, the build problem returns on packages that link to libapr. The patch I proposed fixes this issue for all those other packages.
(In reply to Gordon Bos from comment #20) > The main point about my comment, though reading back maybe not explicitly > clear, is that the failure to link to atomic is recurring over several > packages. So even though the original fix that required a full list of > affected platforms (which didn't include mine) allowed building of libapr, > the build problem returns on packages that link to libapr. > > The patch I proposed fixes this issue for all those other packages. I understand, but that's also not consistent with what I've seen - because no references are emitted to atomics with the configure option? Yesterday, for example, the user in #gentoo couldn't build apache-tools because of this, and after applying the fix I committed, he could.
Sam, I've been running some tests today and found that I am unable to replicate the issue as it was back in May 2023, even with an older version of libapr (1.7.0-r4). I think this may be due to a portage update that now correctly passes the environment, probably this section from the log? =============================== Restore user-defined environment settings... restoring CPPFLAGS to "" setting EXTRA_CPPFLAGS to "-DLINUX -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE" restoring CFLAGS to "-O2 -pipe -march=armv5te" setting EXTRA_CFLAGS to "" restoring LDFLAGS to "-Wl,--as-needed -latomic" setting EXTRA_LDFLAGS to "" restoring LIBS to "" setting EXTRA_LIBS to "-luuid -lcrypt -lpthread" restoring INCLUDES to "" setting EXTRA_INCLUDES to "" =============================== So I can confirm that the proposed patch to libapr configure.in is no longer required for my target system. I can also confirm that your latest fix removes the additional/alternative need to declare LDFLAGS="-Wl,--as-needed -latomic" in package.env for affected packages even though I'm not exactly sure how as unlike the earlier fix ldd does not show the dependency on atomic. Guess that means it must be statically linked in, though I don't detect that in the final libtool line either.
