Date: Fri, 18 Oct 2024 14:19:15 +0000 From: bugzilla-noreply@freebsd.org To: riscv@FreeBSD.org Subject: [Bug 281600] lang/rust failing to build on risc-v (again) Message-ID: <bug-281600-40250-e9vAn01ntR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-281600-40250@https.bugs.freebsd.org/bugzilla/> References: <bug-281600-40250@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281600 --- Comment #26 from Robert Clausecker <fuz@FreeBSD.org> --- (In reply to Mitchell Horne from comment #25) I have commented on this bug not because I am personally interested in Rust, but rather because Rust-based libraries are dependencies to many common por= ts. With Rust broken, a lot of stuff doesn't build or only builds with non-defa= ult options (i.e. is not available using pkg-install(8) unless one manually bui= lds a repository with different options). This means that for me it is very ha= rd to test other ports and packages on riscv64. Sure I can build a kernel with non-default options, but then the patches I write will not be useful to use= rs. I have really tried to have fun working on ports and other projects for riscv64, but there are so many annoyances and roadblocks (chiefly among the= se: a few stupid build system bugs that make the build not self-hosting, and th= is purely ideological issue) that I basically gave up. It doesn't help that we only support less than a handful of boards and they are all dog slow. This summer I then went ahead and mentored a student who was supposed to wr= ite SIMD accelerated libc string functions for Rust. For this purpose, it would have been useful to optionally make use of an ISA extension (specifically, = the Zbb extension) supported by many of the boards out there. Turns out this w= as impossible: there is no way for user software to detect the availability of this feature and we didn't have support for ifunc-based dispatching. While= a patch for the latter was eventually (but way too late to be useful) supplie= d, there seems to be an inability to make any pragmatic decision on ISA extens= ion detection that would have allowed us to carry out this project. Apparently= we are waiting for some RISC-V committee to make a design decision on the perf= ect=E2=84=A2 interface that seems years away. We ended up not pursuing this further aft= er wasting a few weeks and significantly reduced the scope of the GSoC project. The joint factor in all three problems is an absolute refusal of the people working on the riscv64 port to make any sort of pragmatic decisions. Nothi= ng is done anywhere until the perfect final ethernal solution has been obtaine= d.=20 It doesn't matter if user software doesn't run, the system cannot be upgrad= ed, or other developers get blocked with their projects indefinitely. No, ideological purity most be preserved at any cost! Maybe reconsider this approach. Being more pragmatic would seriously help = us make riscv64 FreeBSD a more attractive platform to hack on. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-281600-40250-e9vAn01ntR>