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

[email protected]
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242680

--- Comment #9 from [email protected] ---
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 on the CC list for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.