[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Mon, Nov 03, 2003 at 08:00:37PM +0100, Sven Luther wrote:
> On Mon, Nov 03, 2003 at 06:39:19PM +0100, Sven Luther wrote:
> > Subject: parted: FTBFS : probably due to new glibc and 2.6.0-test linux kernel headers.
> > Package: parted
> > Version: 1.6.6-1.1
> > Severity: important
> > Justification: fails to build from source
> > 
> > i386-linux-gcc -DHAVE_CONFIG_H -I. -I../../libparted -I..  -I../../include -g -O2 -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DLOCALEDIR=\"/usr/share/locale\" -DLOCALEDIR=\"/usr/share/locale\" -W -Wall -Wno-unused -Wno-switch -Wno-format -Werror -c
> > ../../libparted/linux.c  -fPIC -DPIC -o .libs/linux.lo
> > ../../libparted/linux.c: In function `_device_get_length':
> > ../../libparted/linux.c:407: error: parse error before '[' token
> > ../../libparted/linux.c:407: warning: signed and unsigned type in conditional expression
> > 
> > It used to build a few days ago, but this may be due to the new glibc
> > which just did enter unstable, and the kernel headers that go with it, i
> > will investigate.
> 
> The problem comes from /usr/include/linux/fs.h and the :
> 
>   #define BLKGETSIZE64 _IOR(0x12,114,size_t)      /* return device size in bytes (u64 *arg) */
> 
> Definition, which in turn expands in /usr/include/asm/ioctl.h to :
> 
>   #define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
> 
> And in the same file, we see that _IOC_TYPECHECK(size) is :
> 
>   /* provoke compile error for invalid uses of size argument */
>   extern int __invalid_size_argument_for_IOC;
>   #define _IOC_TYPECHECK(t) \
>          ((sizeof(t) == sizeof(t[1]) && \
> 	   sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
> 	   sizeof(t) : __invalid_size_argument_for_IOC)
> 
> BLKGETSIZE64 is used in libparted/linux.c as : 
> 
>   ioctl(arch_specific->fd, BLKGETSIZE64, &bytes)
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: