https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 25 Oct 2017, keno at juliacomputing dot com wrote:
> First, the build process looking for the headers in /sys-include rather
> than /include where glibc installs them. Leads to the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
Keno Fischer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #5 from joseph at codesourcery dot com ---
The expectation for bootstrapping such a cross toolchain is that GCC is
configured and built twice. The first build is static-only, C-only,
inhibit-libc, disables lots of libraries such as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #4 from Keno Fischer ---
Ah, ok sorry I was confused. I probably should have mentioned that I'm doing a
cross compile to a glibc based system, so I'm building the compiler, then
building glibc,
and then going back and building the run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #3 from joseph at codesourcery dot com ---
That's not the test I'm talking about. The relevant one is
gcc/Makefile.in's LIMITS_H_TEST, run during a build stage rather than a
configure stage, so you need to look at the setting of
B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #2 from Keno Fischer ---
It looks like different parts of the build system may be disagreeing on that. I
see
checking limits.h usability... yes
in the log in one place and then
checking limits.h usability... no
later in the same l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #1 from joseph at codesourcery dot com ---
If you have correctly configured GCC so that it can find the system
headers at configure time, include-fixed/limits.h should be constructed as
a concatentation of limitx.h, glimits.h and li
