Date: Sat, 19 Oct 2024 04:40:35 +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-bTfzgOUWOw@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 #29 from dgilbert@eicat.ca --- So the patch, to make this compile and work, is to put COMPAT_FREEBSD11 into the kernel and recompile the kernel. Then things work. Now obviously, several people here understand, but just to be clear: Languages like rust don't use libc (or use it sparingly). In their own equivalent of libc, they call syscalls _directly_. Now, there do not exist ports that sensibly depend on COMPAT_11 on risc-v for FreeBSD because 11 was deprecated before FreeBSD ran on risc-v. But, a language that doesn't use = libc and calls syscalls directly can be written to use the FreeBSD-11 set of syscalls. Technically the nirvana of shared libraries is the idea that a binary can function without even knowing about syscalls --- as they're all provided for the binary --- and provided in updated form such that the binary still runs= .=20 COMPAT and friends are needed, in those cases, when a statically linked bin= ary is in play --- as it might call old syscalls that no longer exist. This is not the play here. Think of rust as an entirely different and some= what incompatible way to generate those binaries, that, from the perview of the = OS, are in the same bin as statically linked. We provide the userland shared libraries --- this "upgrades" most things, but not, sadly, rust. --=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-bTfzgOUWOw>