Re: ipv6 redefinition build issue with 4.15-rc8

[Jonas Bonn]

On 01/17/2018 11:34 PM, Daniel Wagner wrote:
> On 01/17/2018 11:20 PM, Hauke Mehrtens wrote:
> > Do we want to do any changes to the kernel header files? I do not know
> > of any clean workaround to make this work, we can probably hack
> > something for connman, but I think it is not worth the trouble.

Well, it's not _just_ a connman issue, even though it apparently only 
shows up there, currently.

The problem with the kernel patch is that it now pulls in lib-compat.h 
which causes problems if it appears before netinet/in.h.  The following 
code is sufficient to show the issue:

#include <linux/libc-compat.h>
#include <netinet/in.h>
#include <linux/in6.h>

int main(int argc, char** argv)
{
}

lib-compat checks if _NETINET_IN_H is defined... it's not.  So it 
defines __UAPI_DEF_IN6_ADDR.

Then netinet/in.h checks (via bits/in.h) if _LINUX_IN6_H is defined... 
it's not, so it defines the struct in6_addr (and others).

Then linux/in6.h gets pulled in and redefines the function because the 
earlier libc-compat check told it to do so.

If you comment out the first #include statement then it compiles fine.

libc-compat has, as you say, a requirement to be ordered after system 
headers in order for this to work... that doesn't feel terribly robust.

Anyway, the bug is probably in the glibc headers that are not checking 
the __UAPI_DEF*'s but rather using another broken heuristic... right 
place to fix this is probably there.

/Jonas