Split the `-openbsd*` targets by version

[tgross35]

Background

OpenBSD's system interfaces are neither forward- nor backward-compatible, which is somewhat unique among the platforms we support. There are a couple of problems this introduces:

1. Binaries compiled for our generic *-openbsd targets work with an unclear set of OS versions
2. libc has no way to represent changes or removals across versions
3. Informal consensus seems to be that this would prevent the target from getting to tier 2, even with sufficient interest.

Proposal

Replace our generic *-openbsd triples with a versioned triple -openbsdMmm (M = major, m = minor), which will also set target_env. For example, aarch64-unknown-openbsd707correlates to OpenBSD 7.7 (current latest) and will set target_env = "openbsd707". target_env is currently unused on the platform.

This matches the behavior of our QNX Neutrino targets, which have similar version compatibility.

Affected targets:

• aarch64-unknown-openbsd
• i686-unknown-openbsd
• powerpc-unknown-openbsd
• powerpc64-unknown-openbsd
• riscv64gc-unknown-openbsd
• sparc64-unknown-openbsd

All are tier 3.

Note that, as far as I can tell, the major and minor versions don't have any significance (similar to Linux) and roll over after x.9. That is, there is no more compatibility between 6.8 and 6.9 than between 6.9 and 7.0. Releases happen every 6 months.

Unresolved Questions

1. What syntax should be used? -openbsd707 is the format used by qnx-nto, but -openbsd7.7 is easier to read and matches LLVM.
2. Should the existing targets without a version be deprecated, or kept and forward to e.g. the latest release?
3. Do we need to have targets for every version, or can we get by creating a new target only when a breaking change happens?
4. How long should we retain old versions? OpenBSD seems to maintain releases for 1 year.

Alternatives

• RFC: Target extension rfcs#2048 was a proposal to support an OS version, deferred for experimentation.
• There have been proposals that allow specifying versions, most recently RFC: cfg_target_version rfcs#3750. Most of these proposals focus on specifying a minimum version, which isn't sufficient for OpenBSD because of the lack of forward compatibility.

Mentors or Reviewers

Platform maintainer @semarie

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (3 active)

• version-churn
• nonsystematic-breakage
• why-not-ports-rustc

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[workingjubilee]

@rustbot concern version-churn

All OpenBSD versions are "major", according to @semarie, and they seem to do about 2 a year, as compared to QNX's once every 3 years. The sheer amount of work proposed just to add and cycle targets, even just rubberstamping, is rather a lot.

[workingjubilee]

@rustbot concern nonsystematic-breakage

Do we need to have targets for every version, or can we get by creating a new target only when a breaking change happens?

According to @semarie, OpenBSD makes no particularly high effort to determine or maintain compatibility when breaking changes happen. They expect you to rebuild from the new C source code. However, rustc is not a C compiler and does not have a C preprocessor: our extern "C" blocks were designed around the fact that, frankly, OpenBSD's behavior is very unusual, so it is usually reasonable to hand-bind C interfaces. However, with an OS which changes rapidly, we would be simply gambling.

This does not seem very workable. I currently expect we would need to have a system for programmatically adapting to OpenBSD's changes in order to solve the actually important thing of being compatible with OpenBSD code. That, or we would need some other way of actually systematizing our update processes.

[workingjubilee]

@rustbot concern why-not-ports-rustc

Normally, it is often better for something relevant to our internals to live in rust-lang/rust, since we change rapidly and can adapt code to our changes quickly. However, OpenBSD also changes rapidly, in a very similar way, except they also do not have a clear "public interfaces that won't change" boundary. So the question now arises: Why are we going to the effort of maintaining compatibility with them instead of them maintaining compatibility with us? More specifically, we could simply tell people to use their system's compiler, packaged in OpenBSD's ports collection.

Usually we recommend our toolchain, yes, but OpenBSD is unique enough we should confront this question head-on instead of assuming it as a given. We may be paying a higher price than OpenBSD would to maintain compatibility with them. Note this does not need a specific answer, as I intend to accept any justification if T-compiler broadly finds it persuasive, as long as it is somehow distinct from "on principle, because other targets are like this".