This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 5/16/19 3:41 PM, Joseph Myers wrote:
> On Mon, 13 May 2019, Carlos O'Donell wrote:
> 
>>> There are lots of other places with such hardcoded paths.  See e.g. bug 
>>> 20138 asking for --sysconfdir to be respected.  Note that some such paths 
>>> are in installed headers, including paths.h; should those paths in 
>>> installed headers also depend on configure options?
>>  
>> Would the _nl_default_dirname discussion set some precedent for this?
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=14664
>> https://sourceware.org/ml/libc-alpha/2012-12/msg00192.html
> 
> It's certainly relevant.
> 
>> Namely that paths.h is not a part of the ABI, and therefore configure
>> options can and should change the values in the header to match.
> 
> There's a general question here of when installed headers should depend on 
> configure options - because when they do, that sets bounds on what 
> multilib configurations can share a single set of installed headers.  We 
> expect multilib configurations for e.g. -m32 and -m64 to be able to share 
> headers.  Changing paths.h would imply that glibc builds with different 
> paths can't share installed headers.  (An edge case for the question of 
> whether headers can be shared would be e.g. powerpc64 BE and LE - right 
> now I think they can as there are no LE-specific headers, and GCC does 
> have some multilib configurations with both BE and LE multilibs, but those 
> configurations use their own lib* directory names nothing else in the 
> toolchain knows about, so might not work well for other reasons.)
 
My opinion is that having multlibs share headers, particularly for -m32
and -m64 was a design mistake. We should have had completely distinct
headers and keyed the search directory based on the machine being used.

What historical need drove the requirement to share headers? 

Likewise my opinion is that two ABI-compatible toolchains, but compiled
with distinct installed artifact locations, are two distinct runtimes,
and they should have no expectation to be able to share headers.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]