]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/blame - m4/package_urcu.m4
xfs: convert to new timestamp accessors
[thirdparty/xfsprogs-dev.git] / m4 / package_urcu.m4
CommitLineData
e4da1b16
DC
1AC_DEFUN([AC_PACKAGE_NEED_URCU_H],
2 [ AC_CHECK_HEADERS(urcu.h)
3 if test $ac_cv_header_urcu_h = no; then
4 AC_CHECK_HEADERS(urcu.h,, [
5 echo
6 echo 'FATAL ERROR: could not find a valid urcu header.'
7 exit 1])
8 fi
9 ])
10
11AC_DEFUN([AC_PACKAGE_NEED_RCU_INIT],
12 [ AC_MSG_CHECKING([for liburcu])
69d66277
DC
13 AC_COMPILE_IFELSE(
14 [ AC_LANG_PROGRAM([[
e4da1b16
DC
15#define _GNU_SOURCE
16#include <urcu.h>
69d66277
DC
17 ]], [[
18rcu_init();
19 ]])
e4da1b16
DC
20 ], liburcu=-lurcu
21 AC_MSG_RESULT(yes),
22 AC_MSG_RESULT(no))
23 AC_SUBST(liburcu)
24 ])
7448af58
DW
25
26#
27# Make sure that calling uatomic_inc on a 64-bit integer doesn't cause a link
28# error on _uatomic_link_error, which is how liburcu signals that it doesn't
21226bb4
DW
29# support atomic operations on 64-bit data types for its generic
30# implementation (which relies on compiler builtins). For certain archs
31# where liburcu carries its own implementation (such as x86_32), it
32# signals lack of support during runtime by emitting an illegal
33# instruction, so we also need to check CAA_BITS_PER_LONG to detect that.
7448af58
DW
34#
35AC_DEFUN([AC_HAVE_LIBURCU_ATOMIC64],
36 [ AC_MSG_CHECKING([for atomic64_t support in liburcu])
69d66277
DC
37 AC_LINK_IFELSE(
38 [ AC_LANG_PROGRAM([[
7448af58
DW
39#define _GNU_SOURCE
40#include <urcu.h>
21226bb4 41#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
69d66277
DC
42 ]], [[
43long long f = 3;
21226bb4
DW
44
45BUILD_BUG_ON(CAA_BITS_PER_LONG < 64);
69d66277
DC
46uatomic_inc(&f);
47 ]])
7448af58
DW
48 ], have_liburcu_atomic64=yes
49 AC_MSG_RESULT(yes),
50 AC_MSG_RESULT(no))
51 AC_SUBST(have_liburcu_atomic64)
52 ])