From: Jeff Chua <hidden> Date: 2004-10-20 00:58:49
On Tue, 19 Oct 2004, Stephen Hemminger wrote:
Now that 2.6.9 is final. Here is an update of the iproute2 utilities that
can't compile Got the following error. Linux is 2.6.9. Gcc is 2.95.3.
make[1]: Entering directory `/usr/src/net/iproute2-2.6.9/misc'
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include
-DRESOLVE_HOSTNAMES -c -o ss.o ss.c
In file included from /usr/include/asm/byteorder.h:57,
from ss.c:36:
/usr/include/linux/byteorder/little_endian.h:43: parse error before
`__cpu_to_le64p'
/usr/include/linux/byteorder/little_endian.h: In function
`__cpu_to_le64p':
/usr/include/linux/byteorder/little_endian.h:45: `__le64' undeclared
(first use in this function)
/usr/include/linux/byteorder/little_endian.h:45: (Each undeclared
identifier is reported only once
...
a lot of these errors.
These errors went away if linux-2.4.28pre4 is used to compile.
Thanks,
Jeff.
From: Harald Welte <laforge@gnumonks.org> Date: 2004-10-20 07:11:00
On Wed, Oct 20, 2004 at 08:21:10AM +0800, Jeff Chua wrote:
On Tue, 19 Oct 2004, Stephen Hemminger wrote:
quoted
Now that 2.6.9 is final. Here is an update of the iproute2 utilities that
can't compile Got the following error. Linux is 2.6.9. Gcc is 2.95.3.
I'll take care of this. sorry fort he inconvenience.
Thanks,
Jeff.
--
- Harald Welte [off-list ref] http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
From: Harald Welte <laforge@gnumonks.org> Date: 2004-10-20 09:49:24
On Wed, Oct 20, 2004 at 09:00:17AM +0200, Harald Welte wrote:
I'll take care of this. sorry fort he inconvenience.
I should actually read mails befor replying ;) I thought the bug was in
lnstat - but apparently it wasn't.
The include bug seems non-trivial to fix. (how do I hate kernel include
from userspace issues):
apparently __KERNEL_STRICT_NAMES is definde somewhere (glibc?) which
prevents __le16, __le64 and others from being defined in linux/types.h.
Just reietting it like this doesn't help much:
diff -Nru iproute2-2.6.9-041019/ip/iptunnel.c iproute2-2.6.9-laf/ip/iptunnel.c
Since now we have conflicting definitions
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include -DRESOLVE_HOSTNAMES -c -o iptunnel.o iptunnel.c
In file included from /usr/include/linux/byteorder/big_endian.h:11,
from /usr/include/asm/byteorder.h:74,
from iptunnel.c:30:
/usr/include/linux/types.h:20: error: conflicting types for `fd_set'
/usr/include/sys/select.h:78: error: previous declaration of `fd_set'
/usr/include/linux/types.h:21: error: conflicting types for `dev_t'
/usr/include/sys/types.h:62: error: previous declaration of `dev_t'
/usr/include/linux/types.h:24: error: conflicting types for `nlink_t'
/usr/include/sys/types.h:77: error: previous declaration of `nlink_t'
I'm done with this, maybe somebody with more clue about kernel include
magic will take on from this.
Additional issue: the iproute2 makefile didn't stop the build process
in the event of an error. Stephen, plase consider this patch to fix
it:
diff -Nru iproute2-2.6.9-041019/Makefile iproute2-2.6.9-laf/Makefile
--
- Harald Welte <laforge@gnumonks.org> http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
From: David Woodhouse <dwmw2@infradead.org> Date: 2004-10-20 10:53:24
On Wed, 2004-10-20 at 11:41 +0200, Harald Welte wrote:
On Wed, Oct 20, 2004 at 09:00:17AM +0200, Harald Welte wrote:
quoted
I'll take care of this. sorry fort he inconvenience.
I should actually read mails befor replying ;) I thought the bug was in
lnstat - but apparently it wasn't.
The include bug seems non-trivial to fix. (how do I hate kernel include
from userspace issues):
apparently __KERNEL_STRICT_NAMES is definde somewhere (glibc?) which
prevents __le16, __le64 and others from being defined in linux/types.h.
Just reietting it like this doesn't help much:
No, it wouldn't.
The time has come to fix it properly instead. Anything which these tools
actually need from the kernel headers should be moved into a separate
header file (still in the kernel source) which is usable from _both_
kernel and userspace. It should use standard types (like uint16_t etc)
instead of kernel-private types, and shouldn't have any #if{n,}def
__KERNEL__ in it. Ideally, it would be in a different directory too --
but we can worry about that later.
--
dwmw2
From: David Vrabel <hidden> Date: 2004-10-20 11:57:25
David Woodhouse wrote:
The time has come to fix it properly instead. Anything which these tools
actually need from the kernel headers should be moved into a separate
header file (still in the kernel source) which is usable from _both_
kernel and userspace.
Isn't this what linux-libc-headers is for?
It should use standard types (like uint16_t etc)
Why doesn't the kernel use these standard types also?
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
From: David Woodhouse <dwmw2@infradead.org> Date: 2004-10-20 12:22:22
On Wed, 2004-10-20 at 12:52 +0100, David Vrabel wrote:
David Woodhouse wrote:
quoted
The time has come to fix it properly instead. Anything which these tools
actually need from the kernel headers should be moved into a separate
header file (still in the kernel source) which is usable from _both_
kernel and userspace.
Isn't this what linux-libc-headers is for?
The separate linux-libc-headers is a hack, which will be able to die
once we properly clean up the kernel headers into those which are
'exported' and those which are private.
quoted
It should use standard types (like uint16_t etc)
Why doesn't the kernel use these standard types also?
Archaic personal preference. Inside the kernel that's fair enough.
--
dwmw2
same problem.
"#include <linux/tcp.h>" is dragging in "#include <asm/byteorder.h>".
Same thing goes for <linux/ip.h>.
All these kernel headers need cleanup, and I don't know enough to fix it.
Jeff.