[Bug c/80677] New: LIMITS_H_TEST is wrong
helmut at subdivi dot de
gcc-bugzilla@gcc.gnu.org
Mon May 8 18:12:00 GMT 2017
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.
More information about the Gcc-bugs
mailing list