Drop support for FreeBSD 10 and 11 from std

View all comments

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?

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.

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).

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.

@cemeyer

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.

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

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.

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

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.

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.

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

Drop support for FreeBSD 10 and 11 please.

@mirabilos

@mirabilos could you please explain your objection?

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.

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.

@asomers

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.

@asomers

Could somebody familiar with this target (@asomers perhaps) create a platform doc page listing the supported version? Just the template here https://github.com/rust-lang/rust/tree/0f26ee4fd95a1c046582dfb18892f520788e2c2c/src/doc/rustc/src/platform-support and linking the targets to it here https://github.com/rust-lang/rust/blob/0f26ee4fd95a1c046582dfb18892f520788e2c2c/src/doc/rustc/src/platform-support.md. It currently isn't very easy to find supported versions, this is usually a good place for it.

Of note - FreeBSD's wiki seems to list 11.4+ supports Rust, I am not sure how that interacts with what is here https://wiki.freebsd.org/Rust.

Edit: asomers did so at #129220

@tgross35

@tgross35 The oldest FreeBSD release we currently support is 13.3. See this page for details. Is this the information you are looking for?

Do you mean 13.3 is the oldest FreeBSD release that FreeBSD supports, or that is the oldest FreeBSD that rustc is expected to build on? I assumed rustc is somewhere around 12 based on #114521. I was just asking for that (and any other relevant information for building on FreeBSD) to be put into some platform docs so it's a bit easier to find.

@tgross35

@tgross35 The former. As for the latter, I do not have information on that.

@asomers

Could somebody familiar with this target create a platform doc page listing the supported version

Supported FreeBSD releases are listed at https://www.freebsd.org/security/#sup

Looking at the existing we have:
x86_64-unknown-freebsd - Rust tier 2 w/ host tools
i686-unknown-freebsd - Rust tier 2 w/o host tools
aarch64-unknown-freebsd - Rust tier 3 (same for all following)
armv6-unknown-freebsd
armv7-unknown-freebsd
powerpc64-unknown-freebsd
powerpc64le-unknown-freebsd
powerpc-unknown-freebsd
riscv64gc-unknown-freebsd

We also have support for powerpcspe, and 32- and 64-bit big- and little-endian MIPS. MIPS is only supported through 13.x.

x86_64 (aka amd64) and aarch64 are the two Tier-1 architectures for us.

I agree that based on #114521 the minimum FreeBSD version supported by rustc should be 12.x. There's nothing standing in the way of increasing this to 13.x, if someone has a reason to do so.

I'm not yet sufficiently familiar with Rust to populate the doc pages; I'll see if I can work with @asomers to do so (or find someone else).

@asomers

As far as I can tell from this code, we already require FreeBSD 12 when building std. (It's somewhat concerning that this is configured in the libc build script though, shouldn't rustc bootstrap be in charge of setting the right version?)

So -- is there anything left to do for this issue? Cc @asomers @MikaelUrankar

There's still some code in libc/build.rs for FreeBSD 10 and 11 that could be updated or removed, e.g.

    match which_freebsd {
        x if x < 10 => panic!("FreeBSD older than 10 is not supported"),
        10 => set_cfg("freebsd10"),
        11 => set_cfg("freebsd11"),

But I think the main point of this issue (using at least FreeBSD 12's ABI, in particular 64-bit inodes) is complete.

@emaste

There's still one outstanding problem, @emaste @RalfJung : #132185 . When we switched CI to build Rust on FreeBSD 13.4, it produced binaries that segfault when they try to print a stack trace. We've never tracked down the root cause of that bug. It's probably an LLVM bug.

@asomers

@asomers #132185 is now closed; is the issue solved?

@emaste

No, actually it isn't @emaste . I still see occasional segfaults in CI for FreeBSD 13, especially 13.4 and 13.5. But never on 14. I haven't done any more work to investigate this issue for months.

It's worth noting that FreeBSD 13 is scheduled to go EOL in April 2026, so even if the problems with 13 never get resolved we could probably consider jumping directly to 14 in 6 months (minus 6 weeks)

I guess we can drop FreeBSD 13 now, as it is EOL shortly (2026-04-30).

It seems a bit odd discussing dropping support for BSD 13 in an issue called "Drop support for FreeBSD 10 and 11 from std", should we close this issue? Or at least rename it to something like "keeping STD aligned with supported versions of BSD".

It seems a bit odd discussing dropping support for BSD 13 in an issue called "Drop support for FreeBSD 10 and 11 from std"

True. There's also somewhat less motivation to drop support for FreeBSD 12 or later. We wanted to drop support for versions earlier than 12, as they lacked support for 64-bit inodes.

I'd propose to close this issue as (a) the title and description are by now awfully outdated and (b) what's left doesn't seem to be actionable. "We sometimes have crashes on FreeBSD 13" should be tracked as a separate bug. (Or not, given that it is EOL by now.)

Navigation Menu

Repository navigation

Drop support for FreeBSD 10 and 11 from std #89058

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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++

Drop support for FreeBSD 10 and 11 from std #89058

Description

Activity

nagisa commented on Sep 18, 2021

asomers commented on Sep 18, 2021

cemeyer commented on Sep 22, 2021

delphij commented on Sep 22, 2021

laffer1 commented on Sep 22, 2021

bsdimp commented on Sep 22, 2021

bapt commented on Sep 22, 2021

valpackett commented on Sep 22, 2021

dch commented on Sep 22, 2021

dumbbell commented on Sep 22, 2021

MikaelUrankar commented on Sep 22, 2021

asomers commented on Sep 22, 2021

emaste commented on Sep 22, 2021

allanjude commented on Sep 22, 2021

bdrewery commented on Sep 23, 2021

47 remaining items

tgross35 commented on Aug 17, 2024

clausecker commented on Oct 18, 2024

tgross35 commented on Oct 18, 2024

clausecker commented on Oct 18, 2024

emaste commented on Oct 19, 2024

RalfJung commented on Apr 23, 2025

emaste commented on Apr 23, 2025

asomers commented on Apr 23, 2025

emaste commented on Sep 3, 2025

asomers commented on Sep 7, 2025

tgross35 commented on Oct 29, 2025

xtqqczze commented on Mar 16, 2026

RodBurman commented on Jun 1, 2026

emaste commented on Jun 1, 2026

RalfJung commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions