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 2.6.17.6-07202006 which on x86_64-64 give me
[EMAIL PROTECTED] ~ $gcc -ansi -o types types.c [EMAIL PROTECTED] ~ $./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 ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
