It looks as if upstream RISC-V / glibc teams settled on some exciting
new paths to use for

In short, on normal 64 bit hardware which is all we really care about,
it'll use /lib64/lp64d/

For Fedora we've settled on supporting only RV64GC as a baseline,
which means we don't care about hardware which lacks floating point,
nor 32 bit-only hardware since that is likely to be embedded and too
small to run Linux (32 bit embedded hardware is best served by
cross-compilers).  Also because this is a new architecture there is no
legacy of 32 bit binaries that we need to run.

It's possible to change this by building glibc with

  ./configure --libdir=/lib64 [etc]

but it seems that /lib64/lp64d/ is still the default search path
(/lib64 is not searched) even when configuring it like that, so it's a
bit broken.

The question is how does this impact Fedora?  I'm fairly sure we
don't want to change most libraries so they put stuff in /lib64/lp64d/
nor do we want to change %{_libdir} on this one architecture.

We could do a downstream patch.

We could try to change upstream, but this is all now burned into the
glibc 2.27 ABI so it's a bit complicated.

It's possible to use /usr/lib only on riscv64 (isn't that how s390x
works too)?

Any thoughts?


Richard Jones, Virtualization Group, Red Hat
Read my programming and virtualization blog:
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
devel mailing list --
To unsubscribe send an email to

Reply via email to