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
dilfridge@xxxxxxxxxx
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:DilfridgeAttachment:
signature.asc
Description: This is a digitally signed message part.
-- _______________________________________________ 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
