Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

2.6.28 headers break kbd and net-tools userspace builds

6 views
Skip to first unread message

Andrew Walrond

unread,
Jan 22, 2009, 8:00:18 AM1/22/09
to
Breaks kbd like this:

/usr/include/linux/serial.h:164: error: expected
specifier-qualifier-list before '__u32'

and net-tools like this:

In file included from /usr/include/linux/if_tunnel.h:5,
from iptunnel.c:39:
/usr/include/linux/ip.h:85: error: redefinition of 'struct iphdr'

Both build fine with 2.6.27.10 headers.

Hope that's useful.

Andrew Walrond

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Sam Ravnborg

unread,
Jan 22, 2009, 1:00:25 PM1/22/09
to
On Thu, Jan 22, 2009 at 12:45:13PM +0000, Andrew Walrond wrote:
> Breaks kbd like this:
>
> /usr/include/linux/serial.h:164: error: expected
> specifier-qualifier-list before '__u32'

This is know and fixed. The fix is to include linux/types.h
in serial.h.

>
> and net-tools like this:
>
> In file included from /usr/include/linux/if_tunnel.h:5,
> from iptunnel.c:39:
> /usr/include/linux/ip.h:85: error: redefinition of 'struct iphdr'
>
> Both build fine with 2.6.27.10 headers.

Herbert added an include of ip.h in commit:

commit c19e654ddbe3831252f61e76a74d661e1a755530
Author: Herbert Xu <her...@gondor.apana.org.au>
Date: Thu Oct 9 11:59:55 2008 -0700

gre: Add netlink interface

This patch adds a netlink interface that will eventually displace
the existing ioctl interface. It utilises the elegant rtnl_link_ops
mechanism.

This causes struct iphdr to be redefined.
But there is noting wrong in including ip.h in if_tunnel.h.

I checked the include guards and they are correct.

Could you please investige where it picks up the first definition
of struct iphdr.

> Hope that's useful.

Anything that can improve the exported user headers are useful - thanks.

Sam

Andrew Walrond

unread,
Jan 22, 2009, 2:10:15 PM1/22/09
to
Sam Ravnborg wrote:
>
> I checked the include guards and they are correct.
>
> Could you please investige where it picks up the first definition
> of struct iphdr.
>
>
Here you go:

$ make iptunnel.o

cc -D_GNU_SOURCE -O2 -Wall -g -I. -idirafter ./include/ -Ilib -c -o
iptunnel.o iptunnel.c


In file included from /usr/include/linux/if_tunnel.h:5,
from iptunnel.c:39:
/usr/include/linux/ip.h:85: error: redefinition of 'struct iphdr'

$ grep -r iphdr /usr/include/

/usr/include/netinet/ip.h:struct iphdr
/usr/include/netinet/tcp.h: * This should be defined as MIN(512, IP_MSS
- sizeof (struct tcpiphdr)).
/usr/include/linux/if_tunnel.h: struct iphdr iph;
/usr/include/linux/ip.h:struct iphdr {

$ grep netinet/ip.h iptunnel.c

#include <netinet/ip.h>

So linux/ip.h is clashing with glibc(2.8)'s netinet/ip.h

Andrew Walrond

Sam Ravnborg

unread,
Jan 22, 2009, 2:20:10 PM1/22/09
to
[restored lkml]

On Thu, Jan 22, 2009 at 07:03:29PM +0000, Andrew Walrond wrote:
> Sam Ravnborg wrote:
> >
> >I checked the include guards and they are correct.
> >
> >Could you please investige where it picks up the first definition
> >of struct iphdr.
> >
> >

> Here you go:
>
> $ make iptunnel.o
>
> cc -D_GNU_SOURCE -O2 -Wall -g -I. -idirafter ./include/ -Ilib -c -o
> iptunnel.o iptunnel.c

> In file included from /usr/include/linux/if_tunnel.h:5,
> from iptunnel.c:39:
> /usr/include/linux/ip.h:85: error: redefinition of 'struct iphdr'
>

> $ grep -r iphdr /usr/include/
>
> /usr/include/netinet/ip.h:struct iphdr
> /usr/include/netinet/tcp.h: * This should be defined as MIN(512, IP_MSS
> - sizeof (struct tcpiphdr)).
> /usr/include/linux/if_tunnel.h: struct iphdr iph;
> /usr/include/linux/ip.h:struct iphdr {
>
> $ grep netinet/ip.h iptunnel.c
>
> #include <netinet/ip.h>
>
> So linux/ip.h is clashing with glibc(2.8)'s netinet/ip.h

I took a look at my netinet/ip.h and this is obviously
the same structure.
But I do not know what the right answer is here.

Added netdev..

This may be a general thing. Because iphdr is
no a kernel thing, it is an IP thing. So one could argue
that the kernel should not export it in the first place.

David Miller

unread,
Jan 27, 2009, 12:10:13 AM1/27/09
to
From: Sam Ravnborg <s...@ravnborg.org>
Date: Thu, 22 Jan 2009 20:12:39 +0100

> On Thu, Jan 22, 2009 at 07:03:29PM +0000, Andrew Walrond wrote:
> > $ grep -r iphdr /usr/include/
> >
> > /usr/include/netinet/ip.h:struct iphdr
> > /usr/include/netinet/tcp.h: * This should be defined as MIN(512, IP_MSS
> > - sizeof (struct tcpiphdr)).
> > /usr/include/linux/if_tunnel.h: struct iphdr iph;
> > /usr/include/linux/ip.h:struct iphdr {
> >
> > $ grep netinet/ip.h iptunnel.c
> >
> > #include <netinet/ip.h>
> >
> > So linux/ip.h is clashing with glibc(2.8)'s netinet/ip.h
>
> I took a look at my netinet/ip.h and this is obviously
> the same structure.
> But I do not know what the right answer is here.
>
> Added netdev..
>
> This may be a general thing. Because iphdr is
> no a kernel thing, it is an IP thing. So one could argue
> that the kernel should not export it in the first place.

The fly in the ointment is linux/if_tunnel.h

We export a structure there for a userland interface which
uses "struct iphdr".

Because of that, we are faced with the difficult choice between
defining the structure (as we do) in linux/ip.h or using some ugly
__KERNEL__ ifdefs in linux/if_tunnel.h to conditionally include
netinet/ip.h instead. :-/

Really, I have no idea what to do about this as the problem has
existed for so long.

Jan Engelhardt

unread,
Jan 27, 2009, 5:50:04 AM1/27/09
to

On Tuesday 2009-01-27 06:08, David Miller wrote:
>> On Thu, Jan 22, 2009 at 07:03:29PM +0000, Andrew Walrond wrote:
>> > $ grep -r iphdr /usr/include/
>> >
>> > /usr/include/netinet/ip.h:struct iphdr
>> > /usr/include/netinet/tcp.h: * This should be defined as MIN(512, IP_MSS
>> > - sizeof (struct tcpiphdr)).
>> > /usr/include/linux/if_tunnel.h: struct iphdr iph;
>> > /usr/include/linux/ip.h:struct iphdr {
>> >
>> > $ grep netinet/ip.h iptunnel.c
>> >
>> > #include <netinet/ip.h>
>> >
>> > So linux/ip.h is clashing with glibc(2.8)'s netinet/ip.h
>>
>> I took a look at my netinet/ip.h and this is obviously
>> the same structure.
>> But I do not know what the right answer is here.
>>
>> This may be a general thing. Because iphdr is
>> no a kernel thing, it is an IP thing. So one could argue
>> that the kernel should not export it in the first place.
>
>The fly in the ointment is linux/if_tunnel.h
>
>We export a structure there for a userland interface which
>uses "struct iphdr".
>
>Because of that, we are faced with the difficult choice between
>defining the structure (as we do) in linux/ip.h or using some ugly
>__KERNEL__ ifdefs in linux/if_tunnel.h to conditionally include
>netinet/ip.h instead. :-/
>
>Really, I have no idea what to do about this as the problem has
>existed for so long.

I think in the long term, exported structs should probably
have a "kernel_" prefix, much like userspace libraries use
such prefixes to (try to) guard against simple name clashes.

David Miller

unread,
Jan 28, 2009, 3:50:12 PM1/28/09
to
From: Jan Engelhardt <jen...@medozas.de>
Date: Tue, 27 Jan 2009 11:44:51 +0100 (CET)

>
> On Tuesday 2009-01-27 06:08, David Miller wrote:
> >The fly in the ointment is linux/if_tunnel.h
> >
> >We export a structure there for a userland interface which
> >uses "struct iphdr".
> >
> >Because of that, we are faced with the difficult choice between
> >defining the structure (as we do) in linux/ip.h or using some ugly
> >__KERNEL__ ifdefs in linux/if_tunnel.h to conditionally include
> >netinet/ip.h instead. :-/
> >
> >Really, I have no idea what to do about this as the problem has
> >existed for so long.
>
> I think in the long term, exported structs should probably
> have a "kernel_" prefix, much like userspace libraries use
> such prefixes to (try to) guard against simple name clashes.

This is a reasonable rule for future interfaces, but won't
help us here on this one.

For one thing, users can be making use of the inner types
to build the blobs they send via these interfaces. So it's
not like we can rename "struct iphdr" to "struct kernel_iphdr"
to fix this particular case.

Really, we page a huge price these days because the relationship
between glibc's and the kernel's userland header exports in the
past has been anti-social at best.

Jan Engelhardt

unread,
Jan 29, 2009, 11:20:05 PM1/29/09
to

On Wednesday 2009-01-28 21:29, David Miller wrote:
>> On Tuesday 2009-01-27 06:08, David Miller wrote:
>> >The fly in the ointment is linux/if_tunnel.h
>> >
>> >We export a structure there for a userland interface which
>> >uses "struct iphdr".
>> >
>> >Because of that, we are faced with the difficult choice between
>> >defining the structure (as we do) in linux/ip.h or using some ugly
>> >__KERNEL__ ifdefs in linux/if_tunnel.h to conditionally include
>> >netinet/ip.h instead. :-/
>> >
>> >Really, I have no idea what to do about this as the problem has
>> >existed for so long.
>>
>> I think in the long term, exported structs should probably
>> have a "kernel_" prefix, much like userspace libraries use
>> such prefixes to (try to) guard against simple name clashes.
>
>This is a reasonable rule for future interfaces, but won't
>help us here on this one.[...]

>Really, we page a huge price these days because the relationship
>between glibc's and the kernel's userland header exports in the
>past has been anti-social at best.
>
Yeah I just had to notice >:-(

IPPROTO_MH is only defined in linux/in6.h, but inclusion of it:

/usr/include/linux/in6.h:31: error: redefinition of ■struct in6_addr■
/usr/include/linux/in6.h:52: error: redefinition of ■struct sockaddr_in6■
/usr/include/linux/in6.h:60: error: redefinition of ■struct ipv6_mreq■

Ick. That's even worse than tunnels.

Andrew Walrond

unread,
Feb 2, 2009, 5:40:06 AM2/2/09
to
Hey guys. A gentle nudge...

My distro scripts build the

glibc
iproute2
iputils
kbd
lm_sensors
net-tools
strace

packages and others against every new release of linux and linux-stable,
(hence my initial report).
Right now I'm stalled at the 2.6.27.? headers so can't do any more
testing until this is resolved.

Andrew Walrond

David Miller

unread,
Feb 2, 2009, 3:10:18 PM2/2/09
to
From: Andrew Walrond <and...@walrond.org>
Date: Mon, 02 Feb 2009 10:35:25 +0000

> Hey guys. A gentle nudge...
>
> My distro scripts build the
>
> glibc
> iproute2
> iputils
> kbd
> lm_sensors
> net-tools
> strace
>
> packages and others against every new release of linux and linux-stable, (hence my initial report).
> Right now I'm stalled at the 2.6.27.? headers so can't do any more testing until this is resolved.

There isn't anything we can really do about these cases.

No matter what we do, we break the userland build in one way or
another.

Andrew Walrond

unread,
Feb 2, 2009, 4:20:10 PM2/2/09
to
David Miller wrote:
>
> There isn't anything we can really do about these cases.
>
> No matter what we do, we break the userland build in one way or
> another.
>
What exactly is the purpose of the kernel headers? Are there some
definitions in the kernel headers that will never be available from
glibc? Is it perhaps possible to work towards exporting kernel headers
for the sole purpose of building glibc, and all other packages should be
able to build against glibc's headers?

Andrew Walrond

David Miller

unread,
Feb 2, 2009, 4:30:17 PM2/2/09
to
From: David Miller <da...@davemloft.net>
Date: Mon, 02 Feb 2009 13:24:50 -0800 (PST)

> I guess I'll put in the following hack for now:
>
> diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
> index aeab2cb..82c4362 100644

Need to also update linux/Kbuild, here is an updated patch:

diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 12e9a29..6a9bb97 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -89,7 +89,6 @@ header-y += if_ppp.h
header-y += if_slip.h
header-y += if_strip.h
header-y += if_tun.h
-header-y += if_tunnel.h
header-y += in_route.h
header-y += ioctl.h
header-y += ip6_tunnel.h
@@ -235,6 +234,7 @@ unifdef-y += if_phonet.h
unifdef-y += if_pppol2tp.h
unifdef-y += if_pppox.h
unifdef-y += if_tr.h
+unifdef-y += if_tunnel.h
unifdef-y += if_vlan.h
unifdef-y += igmp.h
unifdef-y += inet_diag.h
diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
index aeab2cb..82c4362 100644
--- a/include/linux/if_tunnel.h
+++ b/include/linux/if_tunnel.h
@@ -2,7 +2,10 @@
#define _IF_TUNNEL_H_

#include <linux/types.h>
+
+#ifdef __KERNEL__
#include <linux/ip.h>
+#endif

#define SIOCGETTUNNEL (SIOCDEVPRIVATE + 0)
#define SIOCADDTUNNEL (SIOCDEVPRIVATE + 1)

David Miller

unread,
Feb 2, 2009, 4:30:15 PM2/2/09
to
From: Andrew Walrond <and...@walrond.org>
Date: Mon, 02 Feb 2009 21:13:11 +0000

> What exactly is the purpose of the kernel headers? Are there some
> definitions in the kernel headers that will never be available from
> glibc? Is it perhaps possible to work towards exporting kernel
> headers for the sole purpose of building glibc, and all other
> packages should be able to build against glibc's headers?

To a certain extent they are supposed to be able to
co-exist.

We weren't careful in the past in some cases, to the point
where the conflicts often very difficult to resolve. That's
the kind of situation we have here.

I guess I'll put in the following hack for now:

diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
index aeab2cb..82c4362 100644

--- a/include/linux/if_tunnel.h
+++ b/include/linux/if_tunnel.h
@@ -2,7 +2,10 @@
#define _IF_TUNNEL_H_

#include <linux/types.h>
+
+#ifdef __KERNEL__
#include <linux/ip.h>
+#endif

#define SIOCGETTUNNEL (SIOCDEVPRIVATE + 0)
#define SIOCADDTUNNEL (SIOCDEVPRIVATE + 1)

--

Sam Ravnborg

unread,
Feb 3, 2009, 12:00:15 AM2/3/09
to
On Mon, Feb 02, 2009 at 01:27:23PM -0800, David Miller wrote:
> From: David Miller <da...@davemloft.net>
> Date: Mon, 02 Feb 2009 13:24:50 -0800 (PST)
>
> > I guess I'll put in the following hack for now:
> >
> > diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
> > index aeab2cb..82c4362 100644
>
> Need to also update linux/Kbuild, here is an updated patch:

All headers are unifdeffed - so the Kbuild patch
is not needed.

Sam

David Miller

unread,
Feb 3, 2009, 12:30:12 AM2/3/09
to
From: Sam Ravnborg <s...@ravnborg.org>
Date: Tue, 3 Feb 2009 05:58:33 +0100

> On Mon, Feb 02, 2009 at 01:27:23PM -0800, David Miller wrote:
> > From: David Miller <da...@davemloft.net>
> > Date: Mon, 02 Feb 2009 13:24:50 -0800 (PST)
> >
> > > I guess I'll put in the following hack for now:
> > >
> > > diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
> > > index aeab2cb..82c4362 100644
> >
> > Need to also update linux/Kbuild, here is an updated patch:
>
> All headers are unifdeffed - so the Kbuild patch
> is not needed.

Thanks for the info but that's how I commited and pushed out
the fix already, and it doesn't hurt either :-)

0 new messages