mesa3d: fix build with gcc <= 4.7 on some architectures

The configure.ac check for atomic intrinsics assumes that if an atomic
intrinsic is not available, it's because we must link with
libatomic. Except that libatomic is not always available, for example
with gcc <= 4.7.

To fix this, this commit adds a patch that reworks the atomic check in
configure.ac. It has been submitted upstream, and tested in a number
of different combinations.

Fixes:

  http://autobuild.buildroot.net/results/b045488d880a4013ed82937e7115b7636867e01d/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

diff --git a/package/mesa3d/0003-configure.ac-rework-latomic-check.patch b/package/mesa3d/0003-configure.ac-rework-latomic-check.patch
new file mode 100644 (file)
index 0000000..ee8107d
--- /dev/null
+++ b/package/mesa3d/0003-configure.ac-rework-latomic-check.patch
@@ -0,0 +1,124 @@
+From 5865c7cb4e4ed1d63699e384ea52984448adfec9 Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+Date: Mon, 7 May 2018 10:36:10 +0200
+Subject: [PATCH] configure.ac: rework -latomic check
+
+The configure.ac logic added in commit
+2ef7f23820a67e958c2252bd81eb0458903ebf33 ("configure: check if
+-latomic is needed for __atomic_*") makes the assumption that if a
+64-bit atomic intrinsic test program fails to link without -latomic,
+it is because we must use -latomic.
+
+Unfortunately, this is not completely correct: libatomic only appeared
+in gcc 4.8, and therefore gcc versions before that will not have
+libatomic, and therefore don't provide atomic intrinsics for all
+architectures. This issue was for example encountered on PowerPC with
+a gcc 4.7 toolchain, where the build fails with:
+
+powerpc-ctng_e500v2-linux-gnuspe/bin/ld: cannot find -latomic
+
+This commit aims at fixing that, by not assuming -latomic is
+available. The commit re-organizes the atomic intrinsics detection as
+follows:
+
+ (1) Test if a program using 64-bit atomic intrinsics links properly,
+     without -latomic. If this is the case, we have atomic intrinsics,
+     and we're good to go.
+
+ (2) If (1) has failed, then test to link the same program, but this
+     time with -latomic in LDFLAGS. If this is the case, then we have
+     atomic intrinsics, provided we link with -latomic.
+
+This has been tested in three situations:
+
+ - On x86-64, where atomic instrinsics are all built-in, with no need
+   for libatomic. In this case, config.log contains:
+
+   GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#'
+   GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE=''
+   LIBATOMIC_LIBS=''
+
+   This means: atomic intrinsics are available, and we don't need to
+   link with libatomic.
+
+ - On NIOS2, where atomic intrinsics are available, but some of them
+   (64-bit ones) require using libatomic. In this case, config.log
+   contains:
+
+   GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#'
+   GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE=''
+   LIBATOMIC_LIBS='-latomic'
+
+   This means: atomic intrinsics are available, and we need to link
+   with libatomic.
+
+ - On PowerPC with an old gcc 4.7 toolchain, where 32-bit atomic
+   instrinsics are available, but not 64-bit atomic instrinsics, and
+   there is no libatomic. In this case, config.log contains:
+
+   GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE=''
+   GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE='#'
+
+   With means that atomic intrinsics are not usable.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+Upstream-status: https://lists.freedesktop.org/archives/mesa-dev/2018-May/194214.html
+---
+ configure.ac | 37 +++++++++++++++++++++----------------
+ 1 file changed, 21 insertions(+), 16 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index f1fbdcc6c7..c94e547874 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -433,26 +433,31 @@ fi
+ AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED = x1])
+ AC_SUBST([SSE41_CFLAGS], $SSE41_CFLAGS)
+ 
+-dnl Check for new-style atomic builtins
+-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
++dnl Check for new-style atomic builtins. We first check without linking to
++dnl -latomic.
++AC_LINK_IFELSE([AC_LANG_SOURCE([[
++#include <stdint.h>
+ int main() {
+-    int n;
+-    return __atomic_load_n(&n, __ATOMIC_ACQUIRE);
++    uint64_t n;
++    return (int)__atomic_load_n(&n, __ATOMIC_ACQUIRE);
+ }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=1)
++
++dnl If that didn't work, we try linking with -latomic, which is needed on some
++dnl platforms.
++if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" != x1; then
++   save_LDFLAGS=$LDFLAGS
++   LDFLAGS="$LDFLAGS -latomic"
++   AC_LINK_IFELSE([AC_LANG_SOURCE([[
++   #include <stdint.h>
++   int main() {
++        uint64_t n;
++        return (int)__atomic_load_n(&n, __ATOMIC_ACQUIRE);
++   }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=1 LIBATOMIC_LIBS="-latomic")
++   LDFLAGS=$save_LDFLAGS
++fi
++
+ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
+     DEFINES="$DEFINES -DUSE_GCC_ATOMIC_BUILTINS"
+-    dnl On some platforms, new-style atomics need a helper library
+-    AC_MSG_CHECKING(whether -latomic is needed)
+-    AC_LINK_IFELSE([AC_LANG_SOURCE([[
+-    #include <stdint.h>
+-    uint64_t v;
+-    int main() {
+-        return (int)__atomic_load_n(&v, __ATOMIC_ACQUIRE);
+-    }]])], GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=no, GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=yes)
+-    AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC)
+-    if test "x$GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC" = xyes; then
+-        LIBATOMIC_LIBS="-latomic"
+-    fi
+ fi
+ AC_SUBST([LIBATOMIC_LIBS])
+ 
+-- 
+2.14.3
+