On Wed, 2013-01-16 at 12:04 -0500, Mike Frysinger wrote:

On Wednesday 16 January 2013 10:47:12 Ben Hutchings wrote:

...

On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:

...

Cong Wang wrote:

...

(Cc'ing some glibc developers...)

Hello,

In glibc source file inet/netinet/in.h and kernel source file include/uapi/linux/in6.h, both define struct in6_addr, and both are visible to user applications. Thomas reported a conflict below.

So, how can we handle this? /me is wondering why we didn't see this before.

[...]

...

This is not a new issue. In addition to this, netinet/in.h also conflits with linux/in.h.

We might have

#if !defined(__GLIBC__) || !defined(_NETINET_IN_H)

#endif

around those conflicting definitions in uapi/linux/in{,6}.h.

This only solves half the problem, as <netinet/in.h> might be included after <linux/in.h>. Also, not all Linux userland uses glibc.

certainly true, but the current expectation is that you don't mix your ABIs.

Whose expectation? Which ABIs are being mixed?

if you're programming with the C library API, then use the C library headers. if you're banging directly on the kernel, then use the kernel headers. not saying it's a perfect solution, but it works for the vast majority of use cases.

In practice most C programs for Linux will use a mixture of thinly wrapped system calls and higher-level APIs from the C library, and never really call the kernel directly (as that requires inline assembler). Userland programmers will work around this historical mess by tweaking the #include order or splitting source files. But they shouldn't have to. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.