Bug#218980: parted: FTBFS : probably due to new glibc and 2.6.0-test linux kernel headers.

[Sven Luther <sven.luther@wanadoo.fr>]

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);
                }
        }


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);
                }
        }

And finally the preprocessed function once i remove the _IOC_TYPECHECK call :

        if (_kernel_has_blkgetsize64()) {
                if (ioctl(arch_specific->fd, ((((2U) << (((0 +8)+8)+14))
| (((0x12)) << (0 +8)) | (((114)) << 0) | (((sizeof(uint64_t))) << ((0
+8)+8)))), &bytes) == 0) {
                        return bytes / _device_get_sector_size(dev);
                }
        }

You clearly see that the _IOC_TYPECHECK stuff, which was added to solve
some problem on 32bit userland with 64bit kernels, is the one causing
the problem here, and that the sizeof(sizeof(uint64_t)[1]) is the one
which is causing the error. Even if sizeof(size_t[1]) should be legal
code, i seriously doubt that sizeof(uint64_t)[1] is. I suppose there is
somewhere where size_t is changed to sizeof(uint64_t).

Hope this helps some. If there is a bug in parted, which is possible for
all i know, i will gladly fix it, but this kind of stuff is a bit out of
my depth, and i cannot see all the implications of it.

Friendly,

Sven Luther