On Sun, Nov 09, 2003 at 02:00:55PM +0100, Sven Luther wrote: > On Sun, Nov 09, 2003 at 12:02:05PM +0100, Sven Luther wrote: > > On Mon, Nov 03, 2003 at 02:23:46PM -0500, Daniel Jacobowitz wrote: > > > > I am a bit at a loss on how to solve this problem though. I guess it is > > > > trying to do a sizeof(size_t[1]) which is the cause of the first > > > > problem, and that it is trying to compare sizeof(t) with (1 << > > > > _IOC_SIZEBITS) > > > > which is the cause of the second error. Or maybe the second error is > > > > because the result of sizeof(t) is unsigned while > > > > __invalid_size_argument_for_IOC is not. > > > > > > This macro is there to ensure that people don't use size_t, I thought. > > > I'd have to read the discussion on LKML again though. > > > > The problem is that it is not people who use the size_t macro, but the > > linux-kernel-headers themselves. > > > > Any new on this, it is really a pain to have, since i can't thus > > continue working on parted and at the same time upgrade my system. > > > > Also, it totally breaks building parted, and i feel that it should > > have a priority higher than it has now, not sure though. > > > > Anyway, is there anyway i can help on this, so that it gets solved ? > > Mmm, after reading some LKML threads about this, it seems that the patch > mentioned here : http://lkml.org/lkml/2003/9/30/286 is the one causing > all these problems, and that it was appliead without being fully tested > or something. > > Apparently, the reason for this patch is for cases where the kernel runs > in 64bit mode, but the apps are 32bit ones. > > I will continue looking at this, but i would love to get some > information back from the glibc maintainers too.
Well, how about you at least post a preprocessed test case? sizeof(size_t[1]) should not be a parse error unless you've failed to include something which defines size_t. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
