lkml.org 
[lkml]   [2017]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] uapi: fix linux/if_pppol2tp.h userspace compilation errors
On Tue, Feb 14, 2017 at 02:37:23PM -0500, David Miller wrote:
> From: "Dmitry V. Levin" <ldv@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

\
 
 \ /
  Last update: 2017-02-14 21:30    [W:0.063 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site