Bug#218980: parted: FTBFS : probably due to new glibc and 2.6.0-test linux kernel headers.
On Sun, Nov 09, 2003 at 12:37:08PM -0500, Daniel Jacobowitz wrote:
> On Sun, Nov 09, 2003 at 05:15:03PM +0100, Sven Luther wrote:
> > On Sun, Nov 09, 2003 at 10:54:11AM -0500, Daniel Jacobowitz wrote:
> > > 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.
> >
> > Mmm, ok, will try that.
> >
> > But then, i didn't fail to include anything, this is parted code i
> > didn't even remotely touch. The parted-1.6.6/libparted/linux.c includes
> > are :
> >
> > #include "config.h"
> >
> > #include <parted/parted.h>
> > #include <parted/debug.h>
> > #include <parted/linux.h>
> >
> > #include <ctype.h>
> > #include <errno.h>
> > #include <fcntl.h>
> > #include <stdint.h>
> > #include <stdio.h>
> > #include <string.h>
> > #include <syscall.h>
> > #include <unistd.h>
> > #include <sys/ioctl.h>
> > #include <sys/stat.h>
> > #include <sys/types.h>
> > #include <sys/utsname.h> /* for uname() */
> > #include <scsi/scsi.h>
> >
> > #include "blkpg.h"
> >
> > That said, if linux/fs.h makes use of size_t (which it shouldn't if i
> > have understood the lkml archive correctly), should it not include the
> > necessary stuff for it to work too ?
> >
> > Anyway, here is the original problematic function :
> >
> > if (_kernel_has_blkgetsize64()) {
> > if (ioctl(arch_specific->fd, (BLKGETSIZE64), &bytes) == 0) {
> > return bytes / _device_get_sector_size(dev);
> > }
> > }
>
> Then are you sure you aren't mistaken on where BLKGETSIZE64 comes from.
Well, if i hand modify the /usr/include/asm/ioctl.h, the problem goes
away, but i have not yet tried it with modifying /usr/include/linux/fs.h
to be sure.
BTW, is there another way of being sure of this ?
> You said:
> #define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes (u64 *arg) */
Where is size_t supposed to be defined ?
> > And here the preprocessed function :
> >
> > if (_kernel_has_blkgetsize64()) {
> > if (ioctl(arch_specific->fd, ((((2U) << (((0 +8)+8)+14))
> > | (((0x12)) << (0 +8)) | (((114)) << 0) | (((((sizeof(sizeof(uint64_t))
> > == sizeof(sizeof(uint64_t)[1]) && sizeof(sizeof(uint64_t)) < (1 << 14))
> > ? sizeof(sizeof(uint64_t)) : __invalid_size_argument_for_IOC))) << ((0
> > +8)+8)))), &bytes) == 0) {
> > return bytes / _device_get_sector_size(dev);
> > }
> > }
>
> But that can't expand to that. There's only one sizeof involved.
Well, it should not at least. I will investigate and see if the
linux/fs.h is where it comes from or not. I was not able to find where
the size_t was defined though.
Friendly,
Sven Luther
Reply to: