This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: limits.h
- From: Jim Wilson <wilson at specifixinc dot com>
- To: mail_lists at mail dot ru
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 26 Oct 2003 17:06:26 -0800
- Subject: Re: limits.h
- References: <3F978A26.8020408__12970.6180458472$1066895966@mail.ru>
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.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com