On Fri, Apr 21, 2017 at 11:16:26AM -0400, Carlos O'Donell wrote:
> My opinion is that the upstream kernel UAPI headers continue to change
> without good management of the changes. I have seen at least 3 changes
> which break header inclusion ordering and that would have caused application
> build problems. None of the authors of those changes came to talk to us
> about adding the right guards in glibc to prevent breakage. Worse there
> have been discussions about deleting existing guards, that change would
> break header inclusion order in one of the two directions, just to 
> simplify libc-compat.h in the kernel (avoiding needing any libc-specific
> knowledge). This does not seem conservative enough to me.

Unfortunately, there seems to be no good working synchronization mechanism
proposed yet.  The procedure described in
https://sourceware.org/glibc/wiki/Synchronizing_Headers has severe
problems on the kernel side.  Even with headers that were synchronized
several years ago we have unsolved inclusion issues like this:

$ gcc -xc -c -o/dev/null - <<EOF
#include <linux/in.h>
#include <netinet/in.h>
#include <linux/in6.h> 
EOF

or this:

$ gcc -xc -c -o/dev/null - <<EOF
#include <linux/xattr.h>
#include <netinet/in.h>
#include <linux/in6.h> 
EOF

See also https://sourceware.org/ml/libc-alpha/2017-04/msg00157.html

It's hard to expect that kernel folks would be adding new guards
if already added guards are so fragile.


-- 
ldv