On Fri, Apr 19, 2024 at 8:36 PM Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > > On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote: > > There are multiple PRs and patches floating around that make RISC-V use > > the /usr/lib64 directory, like other 64-bit ports. However, RISC-V > > recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and > > various upstream projects follow that. > > > > I think we should follow upstream, so that it's possible to use Fedora > > to do upstream development without patching the sources, or elaborate > > Fedora-specific configure invocations. The other reasons is to > > future-proof the Fedora port against the arrival of an alternative ABI > > that is not fully backwards-compatible (the same reason why the official > > RISC-V documentation requires use of these paths). > > I just checked in a Debian riscv64 chroot and they don't seem to > follow this recommendation: > > # cat /etc/ld.so.conf.d/riscv64-linux-gnu.conf > /usr/local/lib/riscv64-linux-gnu > /lib/riscv64-linux-gnu > /usr/lib/riscv64-linux-gnu > > This matches what Debian does on all architectures, that is, install > libraries under fully arch-qualified paths. If Debian doesn't stray > from its usual practices for RISC-V, I'm not convinced that Fedora > needs to either. A long time ago /usr/lib64 wasn't even considered as a fallback search path in the linker (for riscv64). Some projects assume /usr/lib64, some explicitly check /usr/lib64/<ABI>, some have fallbacks, some don't IIRC. We currently use a symlink (as Richard) mentioned, but it's not ideal and causes problems (e.g. meson generates wrong paths breaking some packages [one example: libplacebo]). We most likely will not have ABIs installed in parallel, but we might change ABI. Currently Linux distributions target "RV64GC", but we don't really want that for the future RISC-V. I keep telling folks that "RV64GC" is already "a legacy" (10+ years old), but that's the major target for the next few years. We are scheduled to see some RVA22 SBCs this year. RV64GC -> RVA20 -> RVA22 -> RVA23 -> RVA24. That's how things evolved. RVA23 most likely will be ratified soonish. RVA24 is most likely the next major RISC-V Profile from RVI point of view (TBD). Server specifications are based on RVA23 (and will be updated to RVA24 [most likely]). This defines baseline ISA, optional extensions, etc. Palmer sent RFC to libc-alpha to expand glibc targets on RISC-V for testing. This does mention a potential of "lp64dv" ABI maybe for GCC 15. Note that starting RVA23 vectors are required. Google currently picked RVA22 + vectors as their initial baseline ISA for Android. We don't know if the SoC/IP market will follow what Google (Android) decides or the vendor will move fast to newer RISC-V Profiles. >From what I heard at public RVI meeting recordings I would assume that Ubuntu will change their baseline ISA for RISC-V. Back to original topic. The symlink approach is simple, but also a bit ugly (remember meson breaking some packages). We should pick one way, or another. Finally remove the symlink. This might mean a lot of work to cleanup whatever gets broken. We don't really have enough compute to run a full distribution test over a short period of time. Cheers, david > > -- > Andrea Bolognani / Red Hat / Virtualization > -- > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
