On Tue, Aug 21, 2018 at 05:16:50PM +0200, Lukas Czerner wrote: > The issue is in the header files ext2_types.h and blkid_types.h and > those are going to differ depending on architecture. See: > > ... > #if (@SIZEOF_INT@ == 2) > typedef unsigned int __u16; > #else > #if (@SIZEOF_SHORT@ == 2) > typedef unsigned short __u16; > ... > > So this implies that on Fedora / RHEL either asm/types.h doesn't > > exist, or it is not consistent on different platforms? > > Not sure how did you come to this conclusion, but no asm/types.h is not > the problem. On linux most of the blkid_types.h should really be > irrelevant since we should be using linux/types.h, but we're not even > consistent in that. The reason why I suspect this is because we shouldn't be descending into the "#if (@SIZEOF_INT@ == 2)" et. al. branches. That's because we *copy* the types from asm/types.h. From /usr/include/ext2fs/ext2_types.h on Debian: #define __S8_TYPEDEF __signed__ char #define __U8_TYPEDEF unsigned char #define __S16_TYPEDEF __signed__ short #define __U16_TYPEDEF unsigned short #define __S32_TYPEDEF __signed__ int #define __U32_TYPEDEF unsigned int #define __S64_TYPEDEF __signed__ long long #define __U64_TYPEDEF unsigned long long This is done by the config/parse_types.sh script that I was talking about. #ifdef __U16_TYPEDEF typedef __U16_TYPEDEF __u16; #else #if (4 == 2) typedef unsigned int __u16; #else #if (2 == 2) typedef unsigned short __u16; .... (Again, from Debian's /usr/include/ext2fs/ext2_fs.h) So either (a) /usr/include/asm/types.h doesn't exist on Fedora (or Fedora's build environment), or (b) /usr/include/asm/types.h must have inconsistent types on i386 and x86_64. No? - Ted P.S. blkid/types.h shouldn't be used at all, since these days blkid comes from util-linux, not e2fsprogs. I keep blkid in the tree for the benefit of (a) NetBSD, and (b) Android, both of which don't use util-linux. So I'm confused why you are bringing up blkid/types.h? P.P.S. Since you are quoting "#if (@SIZEOF_INT@ == 2)" and not "#if (4 == 2)" I'm guessing you're looking at ext2_types.h.in, and not the actual generated file ext2_types.h. So I guess there's a 3rd possibility, (c) this really isn't a problem on RHEL / Fedora.
