[libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

[Carlos O'Donell]

On 01/16/2013 04:45 PM, David Miller wrote:
> From: Ben Hutchings <bhutchings at solarflare.com>
> Date: Wed, 16 Jan 2013 15:47:12 +0000
> 
>> 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.
> 
> So I've been looking at reasonable ways to fix this.
> 
> What would be really nice is if GCC treated multiple identical
> definitions of structures the same way it handles multiple identical
> definitions of CPP defines.  Which is to silently accept them.
> 
> But that's not the case, so we need a different solution.
> 
> Another thing to do is to use a new structure for in6_addr in kernel
> headers exported to userland.
> 
> If we were to make the structure members and accessor macros identical
> we could avoid breaking most if not all apps.
> 
> However the type name is different so:
> 
> 	struct in6_addr *p = &kern_struct->member;
> 
> wouldn't work so well.  And you couldn't fix up the sources to these
> kinds of accesses in a way that work cleanly both before and after
> changing the kernel headers.
> 
> I'm out of ideas for today.

So I just went down the rabbit hole, and the further I get the
closer I get to having two exact copies of the same definitions
in both glibc and the kernel and using whichever one was included
first.

Is anyone opposed to that kind of solution?

There is some ugliness there.

Cheers,
Carlos.