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

[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'm not sure if anyone cares about strict compliance with FHS though.
Debian (and hence Ubuntu) deliberately violate it with their multiarch
scheme.  RISC-V violates it with our two level scheme for word size
and abi, e.g. /usr/lib64/lp64d for 64-bit hard-float libraries.
Though one person did care enough to report this as a bug.  I sent
email to the fhs-discuss mailing list to ask about this, but never got
a reply.  The email I sent in April is the last email on the mailing
list.  Anyways, I don't care about FHS personally, I just care that I
don't need to change the RISC-V ABI.  If this scheme is OK then maybe
the RISC-V scheme is OK too?

Jim