LIMITS_H_TEST is a Makefile variable defined in gcc/Makefile.in, that determines how to generate its own limits.h, in particular whether to use limitx.h and limity.h. The test simply tests whether $(BUILD_SYSTEM_HEADER_DIR)/limits.h exists and for most practical purposes this tests whether /usr/include/limits.h exists. When the build and target architectures equal, this is fine. When they don't bad things happen. False positives: When building on a typical GNU/Linux system for a baremetal target, the test indicates wrongly indicates success. False negatives: Debian is about to further multiarch. That involves moving libc headers from /usr/include to /usr/include/$(DEB_HOST_MULTIARCH) as libc headers can differ for different libc implementations (glibc/musl/uclibc). Thus the test will wrongly fail even for libcs that provide a limits.h. It seems that the false positive is present since ages and nobody ever noticed. Thus it probably is harmless. The false negative generates a limits.h that disagrees on MB_LEN_MAX with glibc and breaks builds. (# error "Assumed value of MB_LEN_MAX wrong" when including <stdlib.h> after <limits.h>) Thus I propose setting "LIMITS_H_TEST = :" (i.e. always assuming limits.h presence) as an improved heuristic. I also tried invoking $(GCC_FOR_TARGET) -E to check for limits.h presence, but since configure.ac overwrites the GCC_FOR_TARGET defined in gcc/Makefile.in, the required -isystem flags are missing and it has no chance of finding the header.
On Mon, 8 May 2017, helmut at subdivi dot de wrote: > False negatives: Debian is about to further multiarch. That involves moving > libc headers from /usr/include to /usr/include/$(DEB_HOST_MULTIARCH) as libc > headers can differ for different libc implementations (glibc/musl/uclibc). Thus > the test will wrongly fail even for libcs that provide a limits.h. Well, if headers move then configure (and related) tests that look at them will need updating. See how gcc/configure.ac looks in $target_header_dir to identify the glibc version and various other configuration, for example.
(In reply to joseph@codesourcery.com from comment #1) > Well, if headers move then configure (and related) tests that look at them > will need updating. See how gcc/configure.ac looks in $target_header_dir > to identify the glibc version and various other configuration, for > example. As far as I understand it, gcc's build system takes care to consult $(build_tooldir)/sys-include. Debian's packaging of gcc takes care to populate it reasonably. I have performed a fair number of builds of gcc with glibc's headers moved now and cannot confirm the projected behavior. At present, it looks like fixing LIMITS_H_TEST is the remaining piece to the puzzle.
Created attachment 53832 [details] eliminate the need for LIMITS_H_TEST entirely Rather than fix LIMITS_H_TEST, I now propose deleting it. The check that we try to perform at build time with wrong paths can be deferred to runtime and then operated with correct paths. I'm using this patch since at least gcc-11 and only encountered one regression thus far. It triggers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 on hurd, but this is a plain gcc bug that needs fixing anyway, so this should be good to go.
https://gcc.gnu.org/pipermail/gcc/2014-January/211652.html
https://gcc.gnu.org/pipermail/gcc-patches/2017-April/472727.html