[Bug 242680] devel/subversion Fails to build on FreeBSD 12.1-RELEASE-p1 32 bit: libapr-1.so: undefined reference to `__sync_*

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242680

--- Comment #9 from lfmorrison at gmail.com ---
The patch for this problem should actually be applied to apr1, not subversion
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=autoreconf to the
port's makefile.

However, there's already a patch in this port which is applied directly against
configure (not configure.in) and I wasn't sure what would be the correct way 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 generally,
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 missing
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.