This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: limits.h
- From: "Artem B. Bityuckiy" <mail_lists at mail dot ru>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 27 Oct 2003 10:07:00 +0300
- Subject: Re: limits.h
- References: <3F978A26.8020408__12970.6180458472$1066895966@mail.ru> <3F9C6F92.3070408@specifixinc.com>
- Reply-to: mail_lists at mail dot ru
Jim Wilson wrote:
Artem B. Bityuckiy wrote:
I need to have correct MB_LEN_MAX macro in my programs. This correct
value is defined in Newlib's limits.h. But gcc masks Newlib's limits.h
by its own limits.h version witch defines MB_LEN_MAX as 1. GCC's
limits.h doesn't include Newlib's limits.h recursively.
This is a consequence of the fact that typically gcc and newlib are
built in parallel.
If a C library exists while building gcc, then gcc will find the C
library limits.h, and construct a gcc limits.h file that does an
include_next to get it. If no C library exists while building gcc, then
gcc will substitute its own limits.h file. See the LIMITS_H_TEST macro
in the Makefile.
If we build gcc and newlib in parallel, then there is no pre-existing
limits.h file when gcc is built, and hence no #include_next in the gcc
limits.h file.
You can fix this by doing a second build. Build and install gcc. Build
and install newlib. Build and install gcc, and this one should have a
correct limits.h file. I haven't tried this myself, but in theory it
should work.
People doing gcc & glibc builds have had to do something like this for a
long time.
Thank you for answer. I've fixed the problem.
Thanks to Bruce Korbe too.
--
Best Regards
Artem B. Bityckiy