[PATCH 06/18] RISC-V: Add path of library directories for the 32-bit

[Maciej W. Rozycki]

On Thu, 2 Apr 2020, Jim Wilson wrote:

> > diff --git a/sysdeps/unix/sysv/linux/riscv/dl-cache.h b/sysdeps/unix/sysv/linux/riscv/dl-cache.h
> > index c297dfe84f..60fc172edb 100644
> > --- a/sysdeps/unix/sysv/linux/riscv/dl-cache.h
> > +++ b/sysdeps/unix/sysv/linux/riscv/dl-cache.h
> > @@ -34,6 +34,8 @@
> >     RISC-V, libraries can be found in paths ending in:
> >       - /lib64/lp64d
> >       - /lib64/lp64
> > +     - /lib32/ilp32d
> > +     - /lib32/ilp32
> >       - /lib (only ld.so)
> >     so this will add all of those paths.
> >
> 
> FYI This reminds me of something.  I was forwarded a complaint that
> the RISC-V ABI was violating the Filesystem Hierarchy Standard (FHS),
> which specifies that libraries are only allowed to be in /lib and
> /lib<qual>.  The complaint was that /lib64/lp64d doesn't follow this
> pattern, and hence is a violation of this standard.  However, the
> standard doesn't clearly state that <qual> can't contain a slash.  The
> person who complained insisted that it was implied.  It wasn't clear
> to me what to do with the complaint.  Changing the ABI now would be
> rather disruptive and undesirable, and I also don't know how important
> the FHS standard is, or whether this interpretation is correct.

 Hmm, I wonder if there is actually a technical justification for the flat 
structure of library directories, e.g. for automatic library processing by 
some tools based on a flat glob pattern.

 We have a long-established practice to use subdirectories for libraries, 
both for multilibs and for hardware capabilities, and it has been 
considered appropriate, as tree filesystem structures scale better than 
flat ones (large directories require more time to process their entries).

 For instance the MIPS64r3 architecture, which has six base ABIs: 
legacy-NaN-o32, 2008-NaN-o32, legacy-NaN-n32, 2008-NaN-n32, 
legacy-NaN-n64, 2008-NaN-n64, all of which can coexist and independently 
run on a single machine, will keep the 2008-NaN variants in a nan2008/ 
subdirectory of the respective library directories.  There are further 
subdirectories defined for Loongson variants.

 Then ld.so(8) lists the various hardware capabilities the GNU C library's 
dynamic loader will use for various platforms as subdirectories to the 
respective library directories in order to determine the most suitable 
binary variant of the required library to choose.

 Unfortunately while the FHS standard does provide a rationale for many of 
its choices, there does not seem to be one provided for the arrangement of 
library directories chosen.  And the choice made long ago back in 1990s, 
where a typical Linux platform may have had at most two or maybe three 
ABIs defined to choose from based merely of the address space size being 
32-bit or 64-bit, may no longer be adequate some 20 years later as the 
world has evolved.

 Perhaps the choice made long ago for the library locations would best be 
revisited and any technical justification reevaluated.  I would recommend 
approaching The Linux Foundation, the entity backing the standard, with 
this problem.

  Maciej