Hello Frank,
I'm building GPC for arm-elf target. In the source directory in files p/rts/configure.in and rts.h options "_LARGEFILE64_SOURCE" and "_FILE_OFFSET_BITS 64" are hardcoded. Is it really necessary? Is it possible to build GPC without large file support as it doesn't make sense for embedded platforms? It doesn't depend of version of GPC sources.
FH> To put the question the other way around, if it doesn't make sense FH> to use large files on these platforms and causes problems (does FH> it?), then why don't the system headers simply ignore it?
I don't know exactly, perhaps I'm doing something wrong, but I have the problems here. I'm truing to build GPC (of 20030830 version) with gcc of 3.3.1 version for arm-elf target. This GCC uses uClibc instead of glibc, and there is file features.h included in uClibc. It is included, for example, from stdlib.h, which is in turn included from conftest.h from p/rts/configure script. I've configured and built uClibc without large file support. So, when conftest.h declares
#define _LARGEFILE64_SOURCE #define _FILE_OFFSET_BITS 64
system runs into the following strings in features.h:
/* Make sure users large file options agree with uClibc's configuration. */ #ifndef __UCLIBC_HAS_LFS__
/* If uClibc was built without large file support, output an error if * and 64-bit file offsets were requested, output an error. * NOTE: This is probably incorrect on a 64-bit arch... */ #ifdef __USE_FILE_OFFSET64 #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, \ uClibc was built without large file support enabled. #endif
So I get the mentioned error and work of the "configure" script stops. Therefore I was forced to build uClibc with large file support.
Best regards, Igor mailto:marny@rambler.ru