Denys,
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.
Mikko,
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:
https://www.sourceware.org/ml/libc-alpha/2016-06/msg00162.html
Test case:
~~~
#include <linux/in6.h>
#include <netinet/in.h>
int
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