Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
Am Dienstag, 30. April 2024, 19:00:33 +11 schrieb Andrea Bolognani: > > Shouldn't the symlink point in the opposite direction anyway? > /usr/lib64/lp64d is the actual canonical path, /usr/lib64 is just for > compatibility. > > Though apparently (see elsewhere in the thread) Gentoo does it this > way too, so maybe there's something I'm missing that makes the > current direction more desirable. > Apart from certain difficulties in implementing that (as Florian said), telling upstream build systems to install their libraries into /usr/lib64/lp64d breaks too many (wrong) assumptions (of the library directory being one dir level under /usr). We tried and had some surprises. Obviously these are upstream bugs in various packages. I don't remember the details anymore, sorry. Explaining the RISC-V directory structure to people back then was somewhat painful. Today it might be easier. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
> > Just for your information, here's how Gentoo is doing things to stay > compatible > with as many variants as possible: > PS. Stage files are here: https://www.gentoo.org/downloads/#riscv (rv32-ilp32 is still building, rv32 musl is waiting until the worst musl-1.2.5 issues are ironed out...) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
Hi, I'm handling the RISC-V libdirs in Gentoo. > 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. From memory I think as per spec both variants are valid. For more than one ABI, only the latter makes sense of course. (It gets more complicated for 32bit, because there it's /usr/lib versus /usr/lib32/ilp32d ...) Just for your information, here's how Gentoo is doing things to stay compatible with as many variants as possible: 1) Non-multilib setups, 64bit /usr/lib64 2) Non-multilib setups, 32bit: /usr/lib 3) Multilib setups (example with primary ABI lp64d): * The *primary* ABI is using the non-multilib path, to keep binary compatibility /usr/lib64 * All *other* ABI use the multilib, two-level paths: /usr/lib64/lp64 /usr/lib32/ilp32d /usr/lib32/ilp32 * The two-level path of the *primary* ABI is a symlink to the non-multilib path. /usr/lib64/lp64d => /usr/lib64 (or equivalent, /usr/lib64/lp64d => . ) Installing the primary ABI into a two-level libdir is something we tried in the past, but it lead to some pain. There are too many build systems out there that assume that $(get_libdir) has one path level only, and then use expressions like (particularly stupid invented example) CONFIG_FILE=/usr/$(get_libdir)/../../etc/myconfig.conf which leads to chaos once $(get_libdir) outputs "lib64/lp64d" ... Cheers, Andreas (on vacation, expect >24h response times) > 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). -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
