cpp found limits.h in FIXED_INCLUDE_DIR, but not in STANDARD_INCLUDE_DIR
Ian Lance Taylor
Tue Sep 16 11:29:00 GMT 2008
Zhang Le <email@example.com> writes:
> I have just tried gcc 4.4.0_alpha20080912.
> But I encountered some problems related to <limits.h>.
> like SSIZE_MAX/PATH_MAX undefined.
> It turned out that the root cause seems to be gcc used the wrong limits.h, i.e.
> (please see the details at the bottom of this email)
> this file only contains some of the system's max value and it can't replace
> /usr/include/limits.h. Presumably (is it?) cpp will stop searching for limits.h
> when it finds the first one in cpp_include_defaults array. And FIXED_INCLUDE_DIR
> is before STANDARD_INCLUDE_DIR.
> So i am a little confused. How come this works in previous versions?
> BTW, the gcc i used was cross compiled on a x86 host.
> Would you please explain a little bit about how fixed headers are supposed to
> work? Is this a bug or a new feature but i missed something here?
If you are building a cross-compiler, it does not make sense to use
/usr/include/limits.h. gcc is providing a minimal limits.h which
supports everything required by ISO C99. SSIZE_MAX and PATH_MAX are
defined by POSIX, and are inherently dependent on your operating
system. They would normally be provided by the version of limits.h
from your C library.
If you have a C library for your target system which provides
limits.h, then you need to use the --with-sysroot option when
configuring gcc to tell it where to find the target C library.
If you don't have a C library for your target system, then that's the
problem you need to solve first. gcc does not provide a C library.
More information about the Gcc