Bug#857535: gcc-7 wrongly "fixes" limits.h when built against a mutiarch libc
Source: gcc-7
Severity: wishlist
Tags: patch
Control: block 798955 by -1
User: helmutg@debian.org
Usertags: rebootstrap
For coinstalling multiple libcs (e.g. any-gnu-any-any and
any-musl-any-any) or coinstalling glibc for different kernels (e.g.
linux-any and kfreebsd-any), it is necessary to move standard libc
headers (e.g. limits.h) to a multiarch location as they differ across
these configurations. There is bug #798955 to implement this for glibc.
Once #798955 is fixed, gcc-7's fixincludes will wrongly fix limits.h,
because gcc determines its presence using a LIMITS_H_TEST that does not
consider such locations. Thus gcc's limits.h will not include glibc's
and set some macros differently. That leads to conflicts with other
glibc headers and thus to compilation failures in e.g. dash. Changing
LIMITS_H_TEST test to consider such paths causes gcc to properly include
glibc's limits.h again.
I thus propose appending the attached patch to
debian/patches/gcc-multiarch.diff.
The issue affects all versions of gcc, but I believe that there is no
gain in fixing it for any versions < 7.
Helmut
--- a/src/gcc/Makefile.in
+++ b/src/gcc/Makefile.in
@@ -494,7 +494,7 @@
STMP_FIXINC = @STMP_FIXINC@
# Test to see whether <limits.h> exists in the system header files.
-LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ]
+LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h -o -f $(BUILD_SYSTEM_HEADER_DIR)/$(MULTIARCH_DIRNAME)/limits.h ]
# Directory for prefix to system directories, for
# each of $(system_prefix)/usr/include, $(system_prefix)/usr/lib, etc.
Reply to: