On 19 March 2017 at 14:19, Russell Senior <russ...@personaltelco.net> wrote:
>>>>>> "Yousong" == Yousong Zhou <yszhou4t...@gmail.com> writes:
>
> Florian> On 03/17/2017 09:51 PM, Yousong Zhou wrote:
>>>>> The bug appeared in v4.1.0 and was fixed since v4.8.0
>>>>>
>>>>> Fixes FS#620
>>>>>
>>>>> Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com>
>
> Florian> Is there a reason not to upgrade to a newer iproute2 then?
> Florian> Maybe not for the 17.01 branch but for the master branch would
> Florian> not that be preferred? -- Florian
>
>>> There are some unresolved (at least I haven't resolved them) UAPI
>>> problems. I have taken a few runs at it, thus far unsuccessful. Any
>>> help on that would be welcome.
>
> Yousong> Fixing the issue at hand was my intention.
>
> Yousong> To be honest, I did not think much about bumping the version ;)
> Yousong> but can you elaborate what's the UAPI issue with that?
>
> This is the build log from my last run at the problem:
>
> http://sprunge.us/ceIL
>
> It was a build for alix2 on the 4.9 kernel using iproute2-4.10, with
> updated patches.
>
It seems that those __UAPI_DEF_xx are private macros that should be
defined and used by the kernel uapi headers and are not intended to be
defined by others to tailor uapi headers' behaviour.
Looking through the history, the issue should be already there since
the following musl commit: "make netinet/in.h suppress clashing
definitions from kernel headers"
http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
But it reveals itself only after the following kernel commit: "uapi
glibc compat: fix compile errors when glibc net/if.h included before
linux/if.h"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a91cb61bb995e5571098188092e296192309c77
I would suggest reverting the musl change and see if it will work for
iproute2 and how bad it will affect other packages...
A related discussion: http://www.openwall.com/lists/musl/2016/03/03/6
Cheers,
yousong
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
