On Thu, Feb 9, 2023 at 2:24 PM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > On Thu, Feb 09, 2023 at 08:06:33AM -0500, Neal Gompa wrote: > > On Thu, Feb 9, 2023 at 8:01 AM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > > David is building Fedora 37+ for RISC-V: > > > > > > http://fedora.riscv.rocks/koji/ > > > > > > > If I remember rightly, this still doesn't build straight from Fedora > > Dist-Git as not all the RISC-V enablement patches have been upstreamed > > into Fedora packages. > > A small number of packages need to be patched for RISC-V. You can > find the dist-git sources for those here (only packages with > "main-riscv64" branches matter): > > http://fedora.riscv.rocks:3000/explore/repos > > The aim is to get everything upstream / into Fedora. Apologies for the slow reply. We do have a dist-git "overlay" that holds various changes as we build things, or if we need to bump NVR to rebuild something. We typically add ".X.riscv64" into Release: field before %{?dist}. There are two generic issues in Fedora that keep popping up: - Wrong assumption about valgrind. Those are easy to fix, but are in a number of places. Note that valgrind upstreaming will happen relatively soonish too. - Broken *.pc files in a number of packages. Somehow meson comes up with wrong paths if *.pc is wrong on riscv64. That's not the case on other architectures, and might be related to our symlink situations (/usr/lib64/lpd64 points to /usr/lib64). There is also an issue in how sub-word atomics are being handled in riscv64 today. This basically means that packages like to fail building somewhat sporadically. Basically you must link to libatomic and GCC SPEC will do that if -pthread is used (this covers most of the cases, but not all). Also a number of packages don't use -pthread and just -lpthread. There are patches to improve this, but that's more likely GCC 14 material now. A quick "fix" (not the best) would be remove -pthread check and let GCC to attempt linking to libatomic in all cases (--as-needed -latomic). /* Because RISC-V only has word-sized atomics, it requries libatomic where others do not. So link libatomic by default, as needed. */ #undef LIB_SPEC #ifdef LD_AS_NEEDED_OPTION #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \ " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION "}" #else #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC " -latomic " #endif There are other bits like the audit library that so far the upstream maintainer didn't want to merge. It would be nice to handle dist-git stuff this year, especially in Fedora 38 / 39 timeframe. We also deviate from the original Fedora too. We are using newer binutils versions compared to what's in Fedora proper. Our Fedora 37 was built binutils 2.39. Fedora no longer updates GCC/binutils/glibc all in one go. There are future questions that need to be discussed too as we are finally approaching RISC-V profiles (RVA{20,22,23}). Optimized packages or/and full repositories and disk images. Today most communication/announcements happen in Fedora RISC-V Matrix / IRC channels. Cheers, david > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.org > _______________________________________________ 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
