So christmas day linus released 0.9.28, and I just tried building uClibc
against it, and this is what I get building for i686:
CC libc/inet/ether_addr.os
In file included from /home/landley/firmware/firmware/build/cross-compiler-
i686/include/asm/posix_types.h:2,
from /home/landley/firmware/firmware/build/cross-compiler-
i686/include/linux/posix_types.h:47,
from /home/landley/firmware/firmware/build/cross-compiler-
i686/include/linux/types.h:5,
from /home/landley/firmware/firmware/build/cross-compiler-
i686/include/linux/if_ether.h:24,
from ./include/netinet/if_ether.h:26,
from ./include/netinet/ether.h:26,
from libc/inet/ether_addr.c:31:
/home/landley/firmware/firmware/build/cross-compiler-
i686/include/asm/posix_types_32.h:10: error: redefinition of typedef
'__kernel_ino_t'
./include/bits/kernel_types.h:15: error: previous declaration of
'__kernel_ino_t' was here
/home/landley/firmware/firmware/build/cross-compiler-
i686/include/asm/posix_types_32.h:11: error: redefinition of typedef
'__kernel_mode_t'
./include/bits/kernel_types.h:16: error: previous declaration of
'__kernel_mode_t' was here
/home/landley/firmware/firmware/build/cross-compiler-
i686/include/asm/posix_types_32.h:12: error: redefinition of typedef
'__kernel_nlink_t'
./include/bits/kernel_types.h:17: error: previous declaration of
'__kernel_nlink_t' was here
And so on.
I dug down and found that the problem is the #include guards for
posix_types_32.h and posix_types_64.h got renamed as part of the ongoing
architecture unification, so the #ifdefs and #defines that uClibc's
include/bits/kernel_types.h were doing wasn't sufficient anymore. And that's
fine, the names of these #defines are kernel internal nonsense that we really
shouldn't be fiddling with, yet are.
I added an extra case to each of those #ifdefs as a local patch. I went to
check it in but noticed that "kraj" (whoever that is) had already silently
done so without mentioning it here on the list.
My questions are:
1) until uClibc 0.9.30.1 ships, you won't be able to build x86 or x86-64
against current kernel headers anymore. In theory a bugfix only release is a
trivial thing to ship whenever there's a bug needing patching. (It shouldn't
break anything, it's _just_ bugfixes with no new development, that's why you
have them.) Unfortunately, Bernhard's current plan seems to be to ship
0.9.30.1 sometime next year (maybe in the spring), and he won't even guess
whether we'll live to see a 0.9.31 release.
I once again point out that time based releases are a really cool thing, and
point to this Google Tech Talk on why time based releases work better than
"when it's ready" releases, and uses various projects that have switched to
time based releases (debian, gcc, gnome, linux, openoffice, plone, and x.org)
as examples:
http://video.google.com/videoplay?docid=-5503858974016723264
The Linux kernel does time based releases for new development, with bugfix
only dot releases as available in between. (Some of them just have one
bugfix.) It's a good development model.
2) what's include/bits/kernel_types.h _for_? The kernel already has an
#include file that defines these, or else we wouldn't do the song and dance to
avoid having both. Why not just use the kernel one?
Yeah, I looked at the svn history, and it said that back in 2002 some
architectures had broken asm/posix_types.h files which we couldn't use. But
by the same token, some _didn't_, and that was _six_years_ago_. If this is
still broken in any reasonably current kernel (2.6 or 2.4) I think we might
want to let that info be known upstream rather than patching around it in
quite so ugly a way?
Rob
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
