summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKalev Lember <klember@redhat.com>2021-02-08 16:36:13 +0100
committerKalev Lember <klember@redhat.com>2021-02-08 17:41:51 +0100
commitf1b9302a1eba9aa277ecff74653b1e5d2ad3f45e (patch)
treedf5dae5b1ade224658a29dd954101cb119dd7b89
parent203e078fdf31b147312da667cb6a4674e60ffbca (diff)
downloadglib-wip/kalev/decltype-extern-Cplusplus.tar.gz
gmacros: Guard C++ code with extern "C++"wip/kalev/decltype-extern-Cplusplus
A number of C++ consumers are (incorrectly) including glib headers in an extern "C" block, which leads to build failures such as: /usr/include/c++/11/type_traits:56:3: error: template with C linkage 56 | template<typename _Tp, _Tp __v> | ^~~~~~~~ We can easily escape that on the glib side by putting the C++ code in an extern "C++" block. Which technically it's a bug on the consuming program's side, I think it's pragmatic here to work this around on the glib side.
-rw-r--r--glib/gmacros.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/glib/gmacros.h b/glib/gmacros.h
index ca1ecbd0a..404537621 100644
--- a/glib/gmacros.h
+++ b/glib/gmacros.h
@@ -238,7 +238,9 @@
#define glib_typeof(t) __typeof__ (t)
#elif defined(__cplusplus) && __cplusplus >= 201103L
/* C++11 decltype() is close enough for our usage */
+extern "C++" {
#include <type_traits>
+} /* extern "C++" */
#define glib_typeof(t) typename std::remove_reference<decltype (t)>::type
#define glib_typeof_2_68
#endif