kdebase vs. linux headers

Ken Moffat ken at linuxfromscratch.org
Thu Oct 5 14:30:24 PDT 2006

On Thu, Oct 05, 2006 at 08:22:22PM +0100, Matthew Burgess wrote:
> Likewise.  I think I've figured it out.  Try compiling that with:
> # gcc -ansi -o types types.c
> and you'll get:
> In file included from types.c:3:
> /usr/include/linux/joystick.h:131: error: expected 
> specifier-qualifier-list before ‘__s64’
> Taking a look at /usr/include/features.h we see:
> The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__.
> It just so happens that the compilation of kdebase uses the -ansi 
> switch, hence the compilation problem.  Now, I still don't know what the 
> correct solution is.  Do we just kill the -ansi flag from kdebase's 
> compilation?  Looking at linux/joystick.h, I can't see a way of fixing 
> it as int64_t isn't an ANSI type, right?
 No idea about int64_t.  Since I don't have an available test system
for x86 at the moment, I'm sticking with the CLFS headers from which on x86_64-64 give me

ken at bluesbreaker ~ $gcc -ansi -o types types.c
ken at bluesbreaker ~ $./types
__GNUC__ is defined
__STRICT_ANSI__ is defined

 The problem seems to perhaps be specific to x86 and the method of
sanitizing (x86_64-64 doesn't have the conditional, but I can
remember similar pain cross-compiling e2fsprogs for ppc64).

 OK, I've got both sets of x86 headers now.  In CLFS x86 __s64 and
__u64 depend only on __GNUC__ because we sed out
'&& !defined(__STRICT_ANSI__)'.  Me, I've no idea what is
"correct", but I strongly suspect that fedora don't test against
kde, and that both our CLFS headers and the kernel's own may need
attention for x86 with uClibc.  I suppose "correct" comes down to
finding out why asm-i386/types.h has this two-part condition in the
first place.

 How much else in BLFS have you built so far ?

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list