Date: Wed, 22 Sep 2021 16:42:30 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Damjan Jovanovic <damjan.jov@gmail.com> Cc: Alan Somers <asomers@freebsd.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: Using modern APIs in Rust on FreeBSD Message-ID: <YUsyxjks7uwlyhjs@kib.kiev.ua> In-Reply-To: <CAJm2B-kxZyR6O__LMKG4=Ro4_Lv3qCTsnzrWS4siG4cAdASS2g@mail.gmail.com> References: <CAOtMX2jro84X1byF%2B6%2B%2BaWpAkAa5rCsLMEYhyqBoGx7Zh5WY7g@mail.gmail.com> <CAJm2B-kxZyR6O__LMKG4=Ro4_Lv3qCTsnzrWS4siG4cAdASS2g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 22, 2021 at 06:27:09AM +0200, Damjan Jovanovic wrote: > On Wed, Sep 22, 2021 at 6:08 AM Alan Somers <asomers@freebsd.org> wrote: > > > 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. > > > > How exactly is the ABI fossilized? If Rust's FFI uses run-time dynamic > linking, it should be able to use dlvsym() to access the correct version of > libc symbols. No, FFI does not use dynamic linking in dynamic sense, i.e. it does not utilize dlopen/dlsym. Rust directly calls into extern "C" functions, and this is quite useful feature, because using dlsym for everything you need from system libraries is beyond the pain point. Rust can link to specific version of the symbol, and libc uses this feature, like this: #[cfg_attr(all(target_os = "freebsd", freebsd11), link_name = "statfs@FBSD_1.0")] pub fn statfs(path: *const ::c_char, buf: *mut statfs) -> ::c_int; There it requests pre-ino64 statfs(). More, libc already has configurations for freebsd11 and later, as can be seen from the citation above. And I see nothing that would prevent libc from defining freebsd11 and freebsd12 variants of struct stat, struct statfs, struct dirent, and so on. That said, I definitely do not want spend (more) time on this. Due to the way libc is structured, to make an impression that definitions are shared between different *BSDs, it is extremely painful to add new bindings and not break other BSDs. I tried something as simple as adding missing MNT_XXX constants for mnt_flags and gave up after full day when I realized that I have to test on Net/Open/DragonflyBSD as well.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YUsyxjks7uwlyhjs>