[PATCH 00/30] RFC: elf: glibc-hwcaps support

[Florian Weimer]

* Jim Wilson:

> On Mon, Jun 22, 2020 at 8:13 AM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>> With these changes, on a current x86-64 machine (with AVX2-level CPU
>> features), you can drop a shared object into the directory
>>   /usr/lib64/glibc-hwcaps/x86-102
>
> This appears to violate the Filesystem Hierarchy Standard (FHS)
>     https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
> which states that libraries can only be in /usr/lib or /usr/lib<qual>.
> And it is implied but not clearly stated that <qual> is not allowed to
> contain a slash.  There is an exception for applications that can have
> a dir under /usr/lib or /usr/lib<qual>, but glibc isn't an
> application.  Unless maybe you want to claim that ld.so is an
> application and these are ld.so specific files?  But then all
> libraries used by ld.so must be in there which is not true.

I thought about this.  For use with the library path, it has to be a
subdirectory not a sibling directory, otherwise the behavior would be
really surprising.

In the end, it's no different from the "tls" directory we already search
(along with a bunch of others).  I posted a list of the subdirectories
searched on s390x:

  <https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html>

At least the "glibc-hwcaps" name is architecture-independent, and we can
add it to FHS if we wanted.

Thanks,
Florian