Drop support for FreeBSD 10 and 11 from std

[asomers]

Rust's standard library currently uses a FreeBSD 10 compatible ABI. But FreeBSD 10 went EoL on October 31, 2018. And now FreeBSD 11 will itself be EoL on September 30, 2021. Isn't it finally time to drop FreeBSD 10 support and update the standard library's ABI to FreeBSD 12, or at least 11?

[nagisa]

Ultimately users of the platform are best positioned to answer this question. There are probably quite few casual users of FreeBSD developing rustc, so somebody who is actively involved in the FreeBSD community would likely be best positioned to provide some guidance here.

[asomers]

Well, I'm a FreeBSD developer. And I can tell you that we're very proud of our backwards-compatibility, but it doesn't require maintaining new tools for old OS versions. Instead, if a person must use FreeBSD 10, the best way to build new software for it would be to use a snapshot or fork of an old version of the Ports tree. That would include an older version of rustc, one that was known to work with FreeBSD 10. In fact, the ports tree itself quickly drops support for old OS versions (it's in the process of dropping support for 11 right now).

[cemeyer]

I’m also a FreeBSD and Rust developer and would advocate dropping 10 support immediately, and 11 support in a few days, when it is officially EOL.

[delphij]

I'm also a FreeBSD developer and I would second @cemeyer . FreeBSD 10 support should be gone as it's EoL'ed almost 3 years ago, and FreeBSD 11 support would be ended really soon too.

At FreeBSD we are committed to provide backward compatibility for applications compiled for older version of FreeBSD releases by maintaining stable system call interfaces; for C runtime we are providing versioned symbols, so legacy binaries would call the old interfaces, which are usually wrappers of new interfaces. While we are proud that we have provided compatibility shims which worked well for the old binaries, we generally encourage application developers to adopt newer API to take full advantage of the performance improvements and flexibility on newer FreeBSD releases.

[laffer1]

Dropping FreeBSD 10 support is likely fine at this point. I think it's premature with 11, despite the upcoming EOL date.

[bsdimp]

Dropping FreeBSD 10 is fine. There have been no security updates to it in over 3 years, so nobody with any kind of security concerns are still running it. FreeBSD 11 is about to be in the same boat. Unless there's some really compelling application stuck on FreeBSD 11 that can't recompile and redeploy to FreeBSD 12, it would be far more beneficial to update to FreeBSD 12's ABI. Old ABIs are generally only supported on a best-effort basis. Given how far out of date FreeBSD 10 at this point, that best effort decayed to zero long ago.

I believe that community survey has shown that people have completely moved on from FreeBSD 10.

[bapt]

Following the freebsd EOL policy is perfectly fine. FreeBSD 10 support should be dropped now, FreeBSD 11 should be dropped by November 1rst.

[valpackett]

12 is about the only real backwards-incompatible break (64-bit inodes) in a long long time. EoL of everything before that is a great event \o/ Rust definitely should start the move into the ino64 world soon (by the end of the year). IIRC the libc crate already has flags to use newer ABI, so they should become the default.

[dch]

as asomers points out, the FreeBSD ports tree (from which all the packages for end users are built), drops support at the same time. Users who don't stay current with a supported FreeBSD release, will stay on the last rust version that they installed, without a path for upgrade.

[dumbbell]

I agree with the proposal too. It makes sense to drop support for FreeBSD 10 now and 11 once it reaches EOL.

[MikaelUrankar]

Drop support for FreeBSD 10 and 11 please.

[asomers]

@mirabilos could you please explain your objection?

[emaste]

There's a related discussion happening for Go now, although Go's avoidance of libc makes it interesting: golang/go#48164

I agree with dropping FreeBSD 10 support immediately and also agree with moving to 12.x the minimum supported version. However, the official EOL is just over a week from the time I'm writing this comment and I would suggest waiting a short time after that, to allow time for a heads-up on FreeBSD mailing lists or elsewhere.

There are a number of companies and others building products and projects on top of FreeBSD who for better or worse continue to use older, unsupported versions. While it is not reasonable (or possible) to accommodate this case long-term, I'd generally like to avoid forcing them into an urgent and unplanned need to upgrade.

[allanjude]

Specifically, getting to to at least the 12 ABI gets rust onto the good side of the changes to support 64-bit inodes and longer filesystem mountpoints.

[bdrewery]

TLDR, Yes, but just removing everything will cause problems on 12+. Builders need to be updated to 12 first. A lot of these symbols are from 7.0 and were used to support 12...
Edit: Thanks @asomers for #89083 which does that. Most of this is moot then but I'll leave it in case someone wants to understand the full picture here as I linked some of the problems I'm aware of, and the problem is not what it seems.

The issue here is far more complex than it seems and discussed more at rust-lang/libc#570.
This post is long because the premise here is (unintentionally) misleading to those who are not aware of the details. There are symbols bound to versions from FreeBSD 7.0 when symbol versioning was introduced, and from FreeBSD 8 for fstatat(2). There may be some from 10 or 11 somewhere too. If we only drop all of these then Rust will no longer work on FreeBSD 12+.

Isn't it finally time to drop FreeBSD 10 support and update the standard library's ABI to FreeBSD 12

• This only makes sense if the official Rust, and crate, builders are 12, and rustup and git builds on FreeBSD continue to work without external hacks.

It appears the builders are still targeting 11.

• rust/src/ci/docker/host-x86_64/dist-x86_64-freebsd/Dockerfile

  Lines 29 to 32 in 0132f82

  	ENV \
  	AR_x86_64_unknown_freebsd=x86_64-unknown-freebsd11-ar \
  	CC_x86_64_unknown_freebsd=x86_64-unknown-freebsd11-clang \
  	CXX_x86_64_unknown_freebsd=x86_64-unknown-freebsd11-clang++

• rust/src/ci/docker/scripts/freebsd-toolchain.sh

  Line 8 in 0132f82

  freebsd_version=11.4

But FreeBSD 10 went EoL on October 31, 2018. And now FreeBSD 11 will itself be EoL on September 30, 2021.

"10 (or 11) being EOL" is not very relevant here as noted about the use of 7.0 and 8.0 symbol versions. The reasoning for this (rust-lang/libc#937, rust-lang/libc#936 rust-lang/libc#721) was never about 10 or 11. From what I recall it was because the Rust builder (on FreeBSD 10) was generating unversioned symbol usage that broke on 12 with ABI changes there. Rust only knows about the target OS and arch, not release. So the "10/11" compat was for 12. FreeBSD ports had hacks to generate a "working" rust binary but as soon as a crate was used that touched any of the structs from that PR it would blow up. [1] [2] [3] [4]. Using rustup or building rust from git, or using the bootstrap, also would not work as they lacked the patches we were carrying.

Rust's standard library currently uses a FreeBSD 10 compatible ABI

I agree the symbols targetted currently are for "10" (some are 7+) (from libc basically bundling FreeBSD 11 headers), but as far as I know the majority of symbols are used unversioned which is why the problem was present in the first place. That is, I believe that at that time if we purposely bound every symbol to the version of the symbol for that prototype that was copied into the libc header then on 12 it would not have been crashing (unless using an external C library). (Maybe that's a simple compromise regarding #570 but I haven't thought deeply on it.)

Rust should not have any blanket policy of dropping compat/versioned symbols for "EOL" releases - they may be there for a reason that has nothing to do with the specific version. FreeBSD has symbols from 7 and earlier that are still used today and may be bound to at some point. I just want to be sure this is clear as I suspect some of the votes here from fellow FreeBSD devs may be policy votes, rather than informed technical votes. Changing what version is targeted is fine regarding EOL, but symbols are a more nuanced discussion.

Having said all of that, allowing interoperability between rust and external libraries using FreeBSD's current ABI is important and the reasoning for this compat is not there anymore assuming the official Rust builders are upgraded to 12. But someone needs to consider every piece involved in the ecosystem here before rushing a change in because of a date change. 11 being EOL has little to no effect on anything for Rust beyond interoperability.

We really need rust-lang/libc#570 dealt with to have a target containing the FreeBSD release (with proper header sysroots for cross builds or continued FFI use) or libc flags or special crates or whatever. Either way the real problem is the need for investment to solve and maintain the solution, and how that would need to be mimiced for other platforms to be consistent.