Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <CAFbqK8mtYtgLiviaBQvk_hT+yMr2VcNZux_5+c8gN36iCeCCiA@mail.gmail.com>
References: <CAFbqK8m9grXyAV_mWSzMGS12Mikekg6NsOM-B7pkXiXpnWVgZg@mail.gmail.com>
 <794202f5-e993-444f-f3fd-891276795926@monom.org> <b4f9df2d-09cb-b9ba-4742-1957c08a5a51@southpole.se>
 <CAFbqK8mtYtgLiviaBQvk_hT+yMr2VcNZux_5+c8gN36iCeCCiA@mail.gmail.com>
From:   Neil MacLeod <neil@nmacleod.com>
Date:   Wed, 17 Jan 2018 19:31:04 +0000
Message-ID: <CAFbqK8=k0F6Xszz-nu8ECs17ckLiO3h1E_X2SV+cabBUOZxxew@mail.gmail.com>
Subject: Re: ipv6 redefinition build issue with 4.15-rc8
To:     Jonas Bonn <jonas@southpole.se>
Cc:     Daniel Wagner <wagi@monom.org>, Hauke Mehrtens <hauke@hauke-m.de>,
        connman@lists.01.org,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "David S. Miller" <davem@davemloft.net>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

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.
>
> 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@nmacleod.com> 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@southpole.se> 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@lists.01.org
>>> https://lists.01.org/mailman/listinfo/connman
>>
>>
>