[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 bugzilla-noreply at freebsd.org
Sat Jan 4 10:56:39 UTC 2020


--- Comment #5 from lfmorrison at gmail.com ---
(In reply to Piotr Kubaj from comment #4)
That looks promising, but I am not in a position to try switching away from
stable right now. It also looks like that commit deliberately limited its scope
to only the kernel for the time being, with effort in the future to make it
visible to userspace.

In any event, apr is also capable of providing its own workarounds for working
atomically if compiler built-ins are not available. A couple different
approaches are available, ranging from full userspace emulation of atomics
using POSIX mutexes, to some CPU-specific inline assembly to achieve atomic
operations; for powerpc, it is capable of providing a hybrid approach, using
inline assembly for 32-bit atomics and falling back to its POSIX mutex
emulation for 64-bit.

Unfortunately, apr's configure script, as it is currently written, doesn't know
how to deal with a situation in which the compiler provides 32-bit atomic
built-ins, but it doesn't provide corresponding 64-bit built-ins: It just tests
for the usability and correct behavior of the built-in using a host-specific
"int", and if that works then it assumes that corresponding built-ins will be
available for every integer type. That's not currently the case for powerpc.

I can see a few different ways forward:
1) It ought to be possible to force apr to always use mutex atomic emulation
all the time by defining "-DUSE_ATOMICS_GENERIC" in CFLAGS. This would fix
atomic64, but it would also impose unnecessary performance penalties on

2) It also ought to be possible to override the configure script's automatic
determination that compiler built-ins are available, using
"-UHAVE_ATOMIC_BUILTINS" in CFLAGS. For powerpc, if gnu compiler extensions are
enabled, then this ought to result in an inline assembly atomic32 and a mutex
emulated atomic64. Probably a fair compromise.

3) I'd really like to make the configure script a little more intelligent, and
give it the ability to independently detect the presence of atomic32 versus
atomic64 built-ins, and allow the use of built-in atomic32 together with
emulated atomic64. To do this, I think it would also be necessary to patch the
source code to make use of this more fine-grained information.

4) Another option, I suppose, would be to take advantage of the fact that the
compiler does automatically convert attempts to use atomic64 into a function
call. We could and actually supply a fallback to the atomic64 mutex emulation
via a function of the same name. On an architectures where the compiler
built-in is available for both atomic32 and atomic64, the built-in would be
used and the emulation function would go unreferenced. However, on an
architecture which supplies only built-in atomic32 but not atomic64, the
emulation function would be automatically used instead.

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

More information about the freebsd-apache mailing list