mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-11-02 15:46:17 +01:00
[win32] Fix atomic ops on mingw*
Bug 682896 - glib doesn't build on mingw32
This commit is contained in:
parent
e1ccae8416
commit
547221b486
31
configure.ac
31
configure.ac
@ -2373,7 +2373,7 @@ dnl
|
||||
dnl We can currently support the atomic ops natively when building GLib
|
||||
dnl with recent versions of GCC or MSVC. MSVC doesn't run ./configure,
|
||||
dnl so we skip that case here and define G_ATOMIC_LOCK_FREE exactly when
|
||||
dnl we are using GCC.
|
||||
dnl we are using GCC (and not mingw*).
|
||||
dnl
|
||||
dnl Note that the atomic ops are only available with GCC on x86 when
|
||||
dnl using -march=i486 or higher. If we detect that the atomic ops are
|
||||
@ -2385,13 +2385,17 @@ dnl the user had the wrong build environment.
|
||||
dnl We may add other compilers here in the future...
|
||||
|
||||
AC_CACHE_CHECK([for lock-free atomic intrinsics], glib_cv_g_atomic_lock_free, [
|
||||
case $host in
|
||||
*-*-mingw*)
|
||||
glib_cv_g_atomic_lock_free=yes
|
||||
;;
|
||||
*)
|
||||
AC_TRY_COMPILE([],
|
||||
[volatile int atomic = 2;\
|
||||
__sync_bool_compare_and_swap (&atomic, 2, 3);],
|
||||
[glib_cv_g_atomic_lock_free=yes],
|
||||
[glib_cv_g_atomic_lock_free=no])])
|
||||
|
||||
if test "$glib_cv_g_atomic_lock_free" = "no"; then
|
||||
[glib_cv_g_atomic_lock_free=no])
|
||||
if test "$glib_cv_g_atomic_lock_free" = "no"; then
|
||||
SAVE_CFLAGS="${CFLAGS}"
|
||||
CFLAGS="-march=i486"
|
||||
AC_TRY_COMPILE([],
|
||||
@ -2400,16 +2404,25 @@ if test "$glib_cv_g_atomic_lock_free" = "no"; then
|
||||
[AC_MSG_ERROR([GLib must be build with -march=i486 or later.])],
|
||||
[])
|
||||
CFLAGS="${SAVE_CFLAGS}"
|
||||
fi
|
||||
fi
|
||||
;;
|
||||
esac])
|
||||
|
||||
# Some compilers support atomic operations but do not define
|
||||
# __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, like clang
|
||||
if test x"$glib_cv_g_atomic_lock_free" = xyes; then
|
||||
|
||||
case $host in
|
||||
*-*-mingw*)
|
||||
;;
|
||||
*)
|
||||
# Some compilers support atomic operations but do not define
|
||||
# __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, like clang
|
||||
if test x"$glib_cv_g_atomic_lock_free" = xyes; then
|
||||
AC_TRY_COMPILE([],
|
||||
[__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4;],
|
||||
[],
|
||||
[AC_DEFINE(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, 1, [ compiler supports atomic operations])])
|
||||
fi
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
dnl We need a more robust approach here...
|
||||
case $host_cpu in
|
||||
|
Loading…
Reference in New Issue
Block a user