[Bug 281600] lang/rust failing to build on risc-v (again)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281600

--- 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 ports.
With Rust broken, a lot of stuff doesn't build or only builds with non-default
options (i.e. is not available using pkg-install(8) unless one manually builds
a repository with different options).  This means that for me it is very hard
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 users.

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 these:
a few stupid build system bugs that make the build not self-hosting, and this
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 write
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 was
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) supplied,
there seems to be an inability to make any pragmatic decision on ISA extension
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 perfect™
interface that seems years away.  We ended up not pursuing this further after
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.  Nothing
is done anywhere until the perfect final ethernal solution has been obtained. 
It doesn't matter if user software doesn't run, the system cannot be upgraded,
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.