Implement a more reliable detection scheme for os_unfair_lock.
The core issue here is the weak linking of the symbol, and in certain environments--for instance, using the latest Xcode (8.1) with the latest SDK (10.12)--os_unfair_lock may resolve even though you're compiling on a host that doesn't support it (10.11). We can use the availability macros to circumvent this problem, and detect that we're not compiling for a target that is going to support them and error out at compile time. The other alternative is to do a runtime check, but that presents issues for cross-compiling.
This commit is contained in:
parent
32127949a3
commit
eb29d7ec0e
@ -1670,10 +1670,15 @@ dnl Check for os_unfair_lock operations as provided on Darwin.
|
|||||||
|
|
||||||
JE_COMPILABLE([Darwin os_unfair_lock_*()], [
|
JE_COMPILABLE([Darwin os_unfair_lock_*()], [
|
||||||
#include <os/lock.h>
|
#include <os/lock.h>
|
||||||
|
#include <AvailabilityMacros.h>
|
||||||
], [
|
], [
|
||||||
|
#if MAC_OS_X_VERSION_MIN_REQUIRED < 101200
|
||||||
|
#error "os_unfair_lock is not supported"
|
||||||
|
#else
|
||||||
os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
|
os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
|
||||||
os_unfair_lock_lock(&lock);
|
os_unfair_lock_lock(&lock);
|
||||||
os_unfair_lock_unlock(&lock);
|
os_unfair_lock_unlock(&lock);
|
||||||
|
#endif
|
||||||
], [je_cv_os_unfair_lock])
|
], [je_cv_os_unfair_lock])
|
||||||
if test "x${je_cv_os_unfair_lock}" = "xyes" ; then
|
if test "x${je_cv_os_unfair_lock}" = "xyes" ; then
|
||||||
AC_DEFINE([JEMALLOC_OS_UNFAIR_LOCK], [ ])
|
AC_DEFINE([JEMALLOC_OS_UNFAIR_LOCK], [ ])
|
||||||
|
Loading…
Reference in New Issue
Block a user