On Thu, Feb 8, 2018 at 9:03 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx