On Mon, 2019-12-23 at 10:09 +0000, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049
>
> --- Comment #1 from Andreas Schwab <sch...@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?
