This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Fix linux/stddef.h coordination with glibc (Bug 20215)


In recent linux 4.6.0 headers we have this:

git blame include/uapi/linux/stddef.h
607ca46e (David Howells  2012-10-13 10:46:48 +0100 1) #include <linux/compiler.h>
283d7573 (Denys Vlasenko 2016-03-30 00:14:57 +0200 2) 
283d7573 (Denys Vlasenko 2016-03-30 00:14:57 +0200 3) #ifndef __always_inline
283d7573 (Denys Vlasenko 2016-03-30 00:14:57 +0200 4) #define __always_inline inline
283d7573 (Denys Vlasenko 2016-03-30 00:14:57 +0200 5) #endif

The definition of __always_inline breaks certain header include
ordering between glibc and linux headers.


I'm curious if your header include fuzzing script caught this failure?

I am adding a source compile testing framework into glibc's test
framework to add regression tests for these failures, rather than
fuzz the whole set of headers. This way we can cover the problem
from both sides glibc and linux:

Test case:
#include <linux/in6.h>
#include <netinet/in.h>

main (void)
  return 0;
In file included from ../include/sys/cdefs.h:3:0,
                 from ../include/features.h:368,
                 from ../inet/netinet/in.h:21,
                 from ../include/netinet/in.h:3,
                 from ../sysdeps/unix/sysv/linux/tst-ipv6-compat2.c:2:
../misc/sys/cdefs.h:307:0: error: "__always_inline" redefined [-Werror]
 # define __always_inline __inline __attribute__ ((__always_inline__))
In file included from /home/carlos/build/glibc-headers/include/linux/posix_types.h:4:0,
                 from /home/carlos/build/glibc-headers/include/linux/types.h:8,
                 from /home/carlos/build/glibc-headers/include/linux/in6.h:24,
                 from ../sysdeps/unix/sysv/linux/tst-ipv6-compat2.c:1:
/home/carlos/build/glibc-headers/include/linux/stddef.h:4:0: note: this is the location of the previous definition
 #define __always_inline __inline__
cc1: all warnings being treated as errors

The glibc definition, particularly the "__always_inline__" attribute needs
to win out, or we need to use a different name e.g. __glibc_always_inline
or __linux_always_inline. Despite both linux and glibc being part of the
"implementation" we can still run into this kind of namespace conflict.

Right now I've chosen to undefine the kernel version and use the glibc one.

I need to check if the glibc version is sufficient (for linux/swab.h) in the
case of a conflict and the glibc definition is the one that is used.

Regression tested with linux 4.6.0 headers using glibc tests-compile framework.



2016-06-07  Carlos O'Donell  <>

	[BZ #20215]
	* misc/sys/cdefs.h [__GNUC_PREREQ (3,2)]: Undef __always_inline first.
	[!__GNUC_PREREQ (3,2)]: Likewise.

diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h
index 7fd4154..0b4607b 100644
--- a/misc/sys/cdefs.h
+++ b/misc/sys/cdefs.h
@@ -304,8 +304,13 @@
 /* Forces a function to be always inlined.  */
 #if __GNUC_PREREQ (3,2)
+/* The Linux kernel defines __always_inline in stddef.h (283d7573), and
+   it conflicts with this definition.  Therefore undefine it first to
+   allow either header to be included first.  */
+# undef __always_inline
 # define __always_inline __inline __attribute__ ((__always_inline__))
+# undef __always_inline
 # define __always_inline __inline

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]