[PATCH] 2.6.31 kernel broke 0.9.30.1 build for sh4.

Rob Landley rob at landley.net
Fri Sep 18 20:54:21 UTC 2009


On Friday 18 September 2009 09:44:58 Bernhard Reutner-Fischer wrote:
> On Thu, Sep 17, 2009 at 09:19:08PM -0500, Rob Landley wrote:
> >The bits/kernel_types.h file breaks every other kernel release, it's a
> > horrible hack that _really_ needs to be dealt with properly someday.
> >
> >This time, the 32 bit and 64 bit SH architectures were merged, so now the
> >guards look like:
> >
> >#ifndef __ASM_SH_POSIX_TYPES_32_H
> >#define __ASM_SH_POSIX_TYPES_32_H
> >
> >And the header is instead checking:
> >
> >#ifndef __ASM_SH_POSIX_TYPES_H
> >#define __ASM_SH_POSIX_TYPES_H
> >
> >And thus the build breaks.  Attached is a quick stab at fixing it.
>
> Is there some educated guess we could apply clairvoyant to handle
> upcoming breakage in the kernel types?

Nope.  They're free to use any guard headers they like, and change 'em as 
often as they like.  That's a purely internal symbol that uClibc is clearly 
abusing.

The bits/kernel_types.h file combines symbols fromm linux/types.h and 
asm/posix_types.h.  The first of those is based on kernel internal __u32 defines 
and not meant to be casually used from userspace unless you know what you're 
doing, but the second one is cleanly exported (by 2.6 anyway, dunno about 2.4) 
and can be #included without much fuss as far as I can see.

So I suspect what we really should be doing is directly #including 
asm/posix_types.h instead of going to so much trouble to avoid conflicting with 
it.  Jumping through hoops to define the exact same symbols to the exact same 
values _and_ not conflict with the other header that also does that is kind of 
crazy.

That would be a patch something like the attached.  (Plus a similar one for 
every other architecture, which I could whip up if you think it's a decent 
approach.)

> Perhaps you could ask folks to lay down their plan for a scheme they
> intend to pursue for these type-guards in the future? TIA :)
>
> >At some point, a 0.9.30.2 might be nice...
>
> You're aware that we have a 0.9.30 branch, i assume.

I'm not a big fan of git, and don't play with it for fun.  (I'd say git's user 
interface was designed by rabid squirrels, but I suspect the squirrels would 
have done a better job.  I should really set up a git->hg converter, but the 
one built into mercurial turns the busybox archive into sashimi, and I haven't 
spent the time to figure out why yet.  Makes me not trust it on anything 
else...)

> Cherry-pick requests that should be applied to the stable branch are
> welcome (the NO_LONG_DOUBLE_MATH comes to mind..)

I just got it building again, I have some catching up to do to see what's 
changed.

Speaking of which, is there some kind of "state of the uClibc" thing that says 
what the todo items are for the next release and about when it's expected?  As 
far as I can tell the last time it came up was 3 months ago when Natanael Copa 
asked about it on June 17th, and the reply was "you know that NPTL support 
that Steven Hill wrote an OLS paper about a full year before Apple launched 
the iPhone?  Well it's still in a separate branch and we're still waiting for 
that to be merged before we can has new release."  (Even Debian finally broke 
down and went to scheduled releases, but you've heard my rants on that topic 
already...)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.patch
Type: text/x-patch
Size: 1349 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090918/22feced8/attachment.bin>


More information about the uClibc mailing list