Date: Sat, 14 Mar 2020 22:29:35 +0000 From: bugzilla-noreply@freebsd.org To: apache@FreeBSD.org Subject: [Bug 242680] devel/subversion Fails to build on FreeBSD 12.1-RELEASE-p1 32 bit: libapr-1.so: undefined reference to `__sync_* Message-ID: <bug-242680-16115-40CdV2m77X@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-242680-16115@https.bugs.freebsd.org/bugzilla/> References: <bug-242680-16115@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242680 --- Comment #9 from lfmorrison@gmail.com --- The patch for this problem should actually be applied to apr1, not subversi= on itself. I've had a patch for apr1 that seems promising, but it was messy because it added new content to the configure script - and looking at the FreeBSD port maintenance guide, they recommended not applying patches directly against configure, but rather against configure.in and adding USES=3Dautoreconf to = the port's makefile. However, there's already a patch in this port which is applied directly aga= inst configure (not configure.in) and I wasn't sure what would be the correct wa= y to make all these moving parts play nicely together. Basically, my patch takes the existing test in configure.in which checks for compiler built-in atomic operations on an unsigned long, and duplicates it = with a guaranteed 64-bit type. (Autoconf can already ensures that the necessary symbol to represent a 64-bit type is available for the purposes of running = this test.) Then, the next part of my patch was applied against include/arch/unix/apr_arch_atomic.h. In the section dealing with checking to see if autoconf was able to detect the presence of built-in atomics general= ly, it also checked to see if autoconf was able to detect 64-bit atomics specifically; if it did not, then the patch would define NEED_ATOMICS_GENERIC64. Next, in atomic/unix/builtins.c I modified apr_atomic_init() to optionally cascade into apr__atomic_generic64_init() if NEED_ATOMICS_GENERIC64 was defined. Finally, in atomic/unix/builtins64.c, the check for USE_ATOMICS_BUILTINS was replaced with a test for both the presence of USE_ATOMICS_BUILTINS and the absence of NEED_ATOMICS_GENERIC64. This all worked, but I was concerned about any corner cases I might be miss= ing because of the fact that I was overwriting the previously patched version of configure with my patched version of configure.in together with autoreconf. I also didn't have ready access to another platform to test and confirm that things were still running properly there. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-242680-16115-40CdV2m77X>