Date: Sat, 04 Jan 2020 10:56:38 +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-CarvSU61LM@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 #5 from lfmorrison@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 s= cope 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 work= ing 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 t= ests 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 atomic32. 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 mut= ex 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 t= he compiler does automatically convert attempts to use atomic64 into a function call. We could and actually supply a fallback to the atomic64 mutex emulati= on 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. --=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-CarvSU61LM>