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. 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? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
