On Tue, Feb 14, 2017 at 02:37:23PM -0500, David Miller wrote:
> From: "Dmitry V. Levin" <l...@altlinux.org>
> Date: Tue, 14 Feb 2017 13:33:53 +0300
>
> > In file included from /usr/include/linux/l2tp.h:12:0,
> > from /usr/include/linux/if_pppol2tp.h:21,
> > /usr/include/netinet/in.h:31:8: error: redefinition of 'struct in_addr'
>
> This is protected properly by __UAPI_DEF_IN_ADDR, so whichever gets
> included first makes the definition.
>
> This whole thing is designed so that if GLIBC headers are included
> first, __UAPI_DEF_IN_ADDR will be defined to zero, therefore
> linux/in.h won't try to make the definition. Otherwise it will.
>
> The facility should not be so fragile that we have to play all
> kinds of header ordering games. We would be imposing the same
> strange rules on userspace applications including these headers
> which is completely unacceptable.
The facility is so fragile that netinet/in.h cannot be included after
linux/in.h:
$ gcc -S -o/dev/null -xc /dev/null -include /usr/include/linux/in.h -include
/usr/include/netinet/in.h
In file included from <command-line>:32:0:
/usr/include/netinet/in.h:31:8: error: redefinition of 'struct in_addr'
struct in_addr
^~~~~~~
In file included from <command-line>:32:0:
/usr/include/linux/in.h:84:8: note: originally defined here
struct in_addr {
^~~~~~~
> So if the facility isn't working correctly, let's fix that instead
> of fidgeting with include ordering all over the tree.
I don't mind if the whole facility will get fixed someday.
My humble objective was just to fix the regression introduced in v4.10-rc1
by commit 47c3e7783be4.
--
ldv
