Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/17/2018 08:31 PM, Neil MacLeod wrote:
> All
> 
> Further to my previous reply (reproduced below having been bounced by
> linux-kernel) I have successfully built LibreELEC when using the
> ConnMan patch from Jonas - there were no other failures.
> 
> I have also built a number of network related packages (iftop, iperf,
> ngrp, nmap, sshfs, tcpdump, udpxy, wireless-tools), again without
> issue, so this particular 4.15-rc8 kernel change is only affecting
> ConnMan as far as I can tell.

Thanks for testing.

> Regards
> Neil
> 
>> All
>>
>> Many thanks for the replies.
>>
>> To ensure my build environment is sane I tested again without reverting the kernel commit, and reproduced the connman build failure.
>>
>> Next I tested the change suggested by Hauke (kernel patch: http://ix.io/Eh5) and connman fails to build, however it fails with a different error this time: http://ix.io/Eh2
>>
>> I then tested the change suggested by Jonas (connman patch: http://ix.io/Eh6) and connman builds successfully, no failure, so this might be a potential fix.

You should import the libc header files first and then the Linux header
files in user space applications, this is the supported order.

Can you try this patch please:

--- a/src/tethering.c
+++ b/src/tethering.c
@@ -31,11 +31,11 @@
 #include <stdio.h>
 #include <sys/ioctl.h>
 #include <net/if.h>
-#include <linux/sockios.h>
 #include <string.h>
 #include <fcntl.h>
-#include <linux/if_tun.h>
 #include <netinet/in.h>
+#include <linux/sockios.h>
+#include <linux/if_tun.h>
 #include <linux/if_bridge.h>

 #include "connman.h"


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.

Hauke

>> I'll now try a clean build with Jonas' patch and see if any other packages fail to build for the same reason as connman (I'm building a complete embedded distro with about 700 packages).
>>
>> I'll post again later with an update.
>>
>> Thanks
>> Neil
> 
> On 17 January 2018 at 15:25, Neil MacLeod <neil@xxxxxxxxxxxx> wrote:
>> All
>>
>> Many thanks for the replies.
>>
>> To ensure my build environment is sane I tested again without reverting the
>> kernel commit, and reproduced the connman build failure.
>>
>> Next I tested the change suggested by Hauke (kernel patch: http://ix.io/Eh5)
>> and connman fails to build, however it fails with a different error this
>> time: http://ix.io/Eh2
>>
>> I then tested the change suggested by Jonas (connman patch:
>> http://ix.io/Eh6) and connman builds successfully, no failure, so this might
>> be a potential fix.
>>
>> I'll now try a clean build with Jonas' patch and see if any other packages
>> fail to build for the same reason as connman (I'm building a complete
>> embedded distro with about 700 packages).
>>
>> I'll post again later with an update.
>>
>> Thanks
>> Neil
>>
>> On 17 January 2018 at 09:03, Jonas Bonn <jonas@xxxxxxxxxxxx> wrote:
>>>
>>> On 01/17/2018 08:59 AM, Daniel Wagner wrote:
>>>>
>>>> Hi Neil,
>>>>
>>>> On 01/16/2018 07:51 PM, Neil MacLeod wrote:
>>>>>
>>>>> Since this commit in 4.15-rc8:
>>>>>
>>>>>
>>>>> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd
>>>>>
>>>>> building connman 1.35 with glibc 2.26 now fails as follows:
>>>>>
>>>>> http://ix.io/EbP
>>>>>
>>>>> I'm not sure if this is a kernel issue, a glibc issue, or a connman
>>>>> issue.
>>>>>
>>>>> Reverting the kernel commit resolves the issue, but isn't ideal (unless
>>>>> it's the correct solution, of course).
>>>>>
>>>>> Does anyone have any better ideas?
>>>
>>>
>>> Try switching the order of these headers around (src/tethering.c)...
>>> netinet/in.h seems to depend on linux/in.h being included _first_ and it's
>>> presumably being pulled in via linux/if_bridge.h now as a result of the
>>> kernel patch (couldn't immediately see why, though... I suspect the
>>> inclusion of libc-compat.h is the culprit.)
>>>
>>> #include <netinet/in.h>
>>> #include <linux/if_bridge.h>
>>>
>>> Yes, this is a hack and only masks the issue... nonetheless.
>>>
>>> /Jonas
>>>
>>>
>>>>
>>>> Since ConnMan does not redefine 'struct in6_addr' and friends I would say
>>>> it is kernel/glibc header include problem. But I might be wrong here.
>>>>
>>>> @Hauke: Do you happen to know what is going on?
>>>>
>>>> Thanks,
>>>> Daniel
>>>> _______________________________________________
>>>> connman mailing list
>>>> connman@xxxxxxxxxxxx
>>>> https://lists.01.org/mailman/listinfo/connman
>>>
>>>
>>