[Bug other/93049] limits.h generated by fixincludes breaks cross-compilation

Svante Signell svante.signell@gmail.com
Mon Dec 23 15:52:00 GMT 2019


On Mon, 2019-12-23 at 10:09 +0000, schwab@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049
> 
> --- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
> Make sure you have sysroot properly set up so that the gcc Makefile finds the
> system limits.h.

Do you mean this:
tmp/src/gcc-9.2.0/configure --help|grep sysroot
  --with-build-sysroot=SYSROOT
                          use sysroot as the system root during the build
or this:
sed-4.7/configure --help|grep sysroot <empty>
coreutils-8.31/configure --help|grep sysroot <empty>
Linux-PAM-1.3.1/configure --help|grep sysroot
 --with-sysroot[=DIR]    Search for dependent libraries within DIR (or the
                          compiler's sysroot if not specified).

The cross-built gcc, generating code for i686-pc-gnu was created with a a little
hairy bootstrap procedure:
binutils
gnumach headers
hurd headers
first gcc
mig
first glibc
full gcc
full glibc <- This is the gcc built for building the Hurd-executable packages.
(and cross-building these packages is even more hairy)

Back to the fixinclude version of limits.h. Is there any specific reason to set 
MB_LEN_MAX to 1, when the system version use 16? Furthermore, in my
understanding fixincludes was/is mainly used to convert non-posix header files?
Why then chop off the end of the system limits.h:

#ifdef __USE_POSIX
/* POSIX adds things to <limits.h>.  */
# include <bits/posix1_lim.h>
#endif

#ifdef __USE_POSIX2
# include <bits/posix2_lim.h>
#endif

#ifdef __USE_XOPEN
# include <bits/xopen_lim.h>
#endif

It seem like the only file modified by fixincludes is limits.h. Is that file
not-posix compliant enough?



More information about the Gcc-bugs mailing list