Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/18/2018 09:49 AM, Jonas Bonn wrote:
> 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

Florian Weimer said here "A lot of combinations are broken, especially
when kernel headers are included first.":
https://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg1411192.html

That was on a older version of these two patches:
https://www.mail-archive.com/search?l=linux-kernel@xxxxxxxxxxxxxxx&q=subject:%22Re%5C%3A+%5C%5Bmusl%5C%5D+Re%5C%3A+%5C%5BPATCH+resent%5C%5D+uapi+libc+compat%5C%3A+allow+non%5C-glibc+to+opt+out+of+uapi+definitions%22&o=newest&f=1

My understanding is that you should include libc headers before Linux
headers, otherwise you *could* run into problems. There are some
workarounds done to also support including Linux headers first, but they
are not working in all cases.

Hauke