https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
Bug ID: 80677 Summary: LIMITS_H_TEST is wrong Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: helmut at subdivi dot de Target Milestone: --- 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.