[PATCH v3] elf: Add tst-ldconfig-bad-aux-cache test [BZ #18093]

[Carlos O'Donell]

On 5/16/19 4:35 PM, Joseph Myers wrote:
> On Thu, 16 May 2019, Carlos O'Donell wrote:
> 
>> What historical need drove the requirement to share headers? 
> 
> My guess would be that it was more that multilib support (long before 
> sysroots) originally introduced a requirement for separate directories for 
> libraries without introducing such a requirement for headers.  In that 
> context, it was natural to set up headers so they could be shared (with, 
> in glibc's case, special handling for gnu/lib-names.h and gnu/stubs.h).  
> Thus, there is in general in GCC no multilib-specific include directory 
> (no analogue of lib / lib64 / libx32 etc. directories for headers), 
> although it's possible to define SYSROOT_HEADERS_SUFFIX_SPEC (but most 
> configurations defining SYSROOT_SUFFIX_SPEC, possibly to an 
> automatically-generated definition based on the multilib configuration, do 
> not define SYSROOT_HEADERS_SUFFIX_SPEC).

This is exactly the answer I expected and in line with my own experience.

In summary then, I think we should do no additional work to allow multiple
differently configured glibc's to share the same headers, particularly
/usr/include/paths.h (default install directory). If you wish to have
differently configured installs then you will need a uniquely configured
sysroot that is possibly triggered via a compiler spec file given a special
option (reminds me of -msgxx-glibc in the CodeSourcery toolchains).

I also think we should encourage the GNU Toolchain to move in a direction
where the various multilib targets do not need to share headers. This sharing
causes real problems in downstream where tooling cannot use "noarch" because
the headers are really "only 2 arch" and then we need special support for
i686 vs. x86_64 headers being interchangeable and correct. Basically the
upstream GNU toolchain never considered how a downstream would package this
kind of shared-header support.

-- 
Cheers,
Carlos.