This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
check-local-headers versus Debian-style multiarch
- From: Zack Weinberg <zackw at panix dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Cc: Joseph Myers <joseph at codesourcery dot com>, David Miller <davem at davemloft dot net>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Date: Thu, 1 Jun 2017 11:39:09 -0400
- Subject: check-local-headers versus Debian-style multiarch
- Authentication-results: sourceware.org; auth=none
check-local-headers ignores headers found in a subdirectory of
/usr/include whose name has the form of a config.sub triple
(specifically, /usr/include/(.*-.*-.*|.*-.*)/) This appears to have
been originally added to the script in 2012 by Dave Miller, with the
comment "Fix check-local-headers.sh on multiarch systems." The variant
with only one dash was added by Samuel Thibault with the comment "Add
more hurd exception to local headers list".
This is problematic for Debian-style multiarch, which I just tripped
over in the form of
https://sourceware.org/bugzilla/show_bug.cgi?id=21514 -- in that
environment, /usr/include and /usr/include/$(canonical_host) are
independent include search path entries, so, for instance, a header
/usr/include/x86_64-linux-gnu/bits/syscall.h will satisfy #include
<bits/syscall.h>, but we don't want it to in a glibc build.
I'm tempted to take this back out, but before I do, was/is there
another multiarch arrangement where people would be expected to write
things like #include <i686-pc/bits/syscall.h>? Or is that normal for
some headers on the Hurd? It's unfortunate that we cannot determine
the name actually used in #include from a .d file.
zw