On Mon, Apr 22, 2024 at 1:08 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Daniel P. Berrangé: > > > 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. > > > > I'm not convinced that using /usr/lib64/lp64d would lead to > > *less* patching. > > > > Apps targetting Fedora are long used to having to adapt from > > using /usr/lib to /usr/lib64. > > But that's largely baked into the upstream defaults by now (unlike the > Debian multi-arch paths). > > > Introducing the use of /usr/lib64/lp64d instead, just for RiscV, feels > > likely to break expectations resulting in apps which build fine on all > > Fedora arches except for RiscV > > I don't want us to have RPM spec file hacks just to get RISC-V to > install in the correct locations. The symbolic link evidently does not > cover all cases. This is quite rare considering that there are ~24K packages in Fedora. I have been looking at packages/SPECs for years now, and I wouldn't be surprised that the amount of modifications (%ifarch riscv64 and similar) is less than for other supported arches in Fedora. The symlink was approved (by Carlos IIRC) back in 2018. We only added it to GCC and glibc. What we never did was introduce it properly into the filesystem package. That means we sometimes get buildroots that lack the symlink (very rare). We don't have control on dlopen(), DT_RUNPATH, DT_RPATH, etc. We don't know if applications will look for libraries in /usr/lib64/lp64d and will they fallback to /usr/lib64. Otherwise the smallest delta between upstream Fedora and Fedora/RISCV was ~1500 packages. There are ~1000 packages that typically don't build in general. Those ~500 contain various things like broken *.pc files, meson producing wrong paths (fixed since yesterday), -mach=native (surprise!), -m64, not supported packages in general (needs ExcludeArch: update), etc. We are building GCC with multilib enabled, but a single ABI selected (lp64d). We are doing this because it was the only way to get sane (i.e. expected) paths for libraries. The last time we checked it, disabling multilib means that libraries get installed into /usr/lib and not /usr/lib64. Again that still doesn't solve the problem as some applications will only check /usr/lib64/lp64d without a fallback to /usr/lib64. Cheers, david > > Whatever we do, it should be upstream. Maybe convince RISC-V to adopt > /usr/lib64. Or have the RISC-V folks implement automated detection of > path layout in autotools, Meson etc., so that out of the box, both paths > work. > > Thanks, > Florian > -- > _______________________________________________ > 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
