Using modern APIs in Rust on FreeBSD

From: Alan Somers <asomers_at_freebsd.org>
Date: Wed, 22 Sep 2021 04:07:26 UTC
tldr; should the Rust ecosystem ditch FreeBSD 10 compat for new code?

Rust uses FFI to talk to the OS's C library.  That makes cross-compiling a
breeze.  Unfortunately, it also fossilizes the ABI.  FreeBSD's libc makes
careful use of ELF symbol versioning.  That's how we were able to change
ino_t to 64-bits while maintaining backwards-compatibility with old
binaries, for example.  But the Rust toolchain isn't able to take
advantage.  Right now, the toolchain uses a FreeBSD 10 ABI, and the libc
crate (which virtually all crates depend on) uses a FreeBSD 11 ABI.  That
means, for example, that no crate can use:
* The offset field in a struct dirent
* 64-bit nlink_t
* 64-bit ino_t
* No NOTE_ABSTIME with kevent
* filesystem and mountpoint names in statfs(2) limited to 88 characters

Until somebody fixes that hard problem, the easy thing for Rust to do would
be to drop support for EoL versions. FreeBSD 10 has been EoL for nearly 3
years, and FreeBSD 11 will be EoL in a few days.  I for one think that it
would be fine for new Rust toolchains and libc releases to drop support for
FreeBSD 10 and 11.  People who need to build for old releases can easily
get old toolchains from rustup, or even from old Ports snapshots.  But the
Rust core developers are conservative, and don't want to upset users of a
platform that many of them don't understand.

Do you agree with me?  If so (or even if you don't), make some noise on
this Github issue!  Give the Rust core team the confidence they need to
move forward.

https://github.com/rust-lang/rust/issues/89058

-Alan