On Thu, Feb 8, 2018 at 9:03 AM, Richard W.M. Jones <rjo...@redhat.com> wrote:
> It looks as if upstream RISC-V / glibc teams settled on some exciting
> new paths to use for libc.so.6:
>   https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html
> In short, on normal 64 bit hardware which is all we really care about,
> it'll use /lib64/lp64d/libc.so.6.
> 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.

I think this probably indicates we should figure out a way to support
upstream layout.

> 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.

I don't like this, and I think it's probably a bad idea to try to change this.

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

No, the only arch that ever did this was Alpha. All currently
supported 64-bit arches use /usr/lib64 for the 64-bit libraries.

> Any thoughts?

Plenty. :)

真実はいつも一つ!/ Always, there's only one truth!
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to