Add Rust 1.86.0 DragonFly bootstrap

[lileding]

Summary:

• add Rust 1.86.0 bootstrap files for x86_64-unknown-dragonfly
• use Rust 1.85.1 as the bootstrap compiler
• carry the DragonFly patches and vendor checksum fixups needed for 1.86.0

Verification:

• built locally with: CLEAN=1 DISTFILES_DIR=~/rust/distfiles ./build-local.sh ~/rust/build-1.86.0
• xbuild completed successfully
• x.py test completed successfully in 0:19:58
• representative test suites: UI 18302 passed / 0 failed / 262 ignored; run-make 287 passed / 0 failed / 94 ignored; rustdoc-ui 307 passed / 0 failed / 7 ignored; rustdoc-json 138 passed / 0 failed; bootstrap 73 passed / 0 failed
• x.py dist completed successfully in 0:18:38
• x.py install completed successfully in 0:02:15
• installed rustc: rustc 1.86.0 (05f9846f8 2025-03-31), host x86_64-unknown-dragonfly, LLVM 19.1.7
• installed cargo: cargo 1.86.0 (adf9b6ad1 2025-02-28), host x86_64-unknown-dragonfly

[tuxillo]

Can you update the checksum?

download: rustc-1.86.0-src.tar.gz from https://static.rust-lang.org/dist and store into /usr/obj/rust-1.86.0
/usr/obj/rust-1.86.0/rustc-1.86.0-src.tar.gz           574 MB   39 MBps    14s
checksum ok for rustc-1.86.0-src.tar.gz
  270104
DOWNLOAD COMPONENT: cargo-1.85.1
download: cargo-1.85.1-x86_64-unknown-dragonfly.tar.xz from https://leaf.dragonflybsd.org/~tuxillo/archive/rust/1.85.1 and store into /usr/obj/rust-1.86.0
/usr/obj/rust-1.86.0/cargo-1.85.1-x86_64-unkno        9065 kB   97 MBps    00s
checksum mismatch. expected: 74809bd38062b087d86bf10ee9fa02eaa9f4fd2dafa6fc7d3c75cf475f2345bc. given: b97fcaf5b9281ca6b130881303012f93d94e0a565ae2ced2fa1fbf5a525e9706

So that it matches what we have in leaf (I built and uploaded 1.85.1 already)

[lileding]

Updated, thanks. I checked all three 1.85.1 bootstrap components currently on leaf and refreshed the cargo, rustc, and rust-std checksums.

[lileding]

Hi @tuxillo,

A related workflow question: I’m planning to continue this work up to Rust 1.96, and after that keep DragonFly updated alongside each upstream Rust stable release.

I understand that the bootstrap chain still needs to be reproducible version by version, so I’m not proposing to skip intermediate bootstraps.

Would it help reduce your maintenance work if I prepare the patches for several upcoming Rust versions in order, and you build/upload them in one batch on leaf? For example, once 1.86 is settled, I can prepare 1.87, 1.88, ... as separate ordered branches/patchsets, each built and fully tested locally from the previous bootstrap. Then you could reproduce them sequentially and upload the resulting tarballs in one maintenance session.

I’m happy to keep submitting one PR per version if that is easier for review, or arrange the patchsets in whatever format is most convenient for you.

[tuxillo]

Yes, whatever you think it is easier for you. This repo is the initial bootstrap we had for Rust (created by @mneumann) but FreeBSD already has bootstrap ports and I think we should follow those. The problem is that we are really behind Ports so this repo will always make sense.

[mneumann]

On Tue, Jun 23, 2026 at 01:34:58PM -0700, Antonio Huete Jimenez wrote: tuxillo left a comment (DragonFlyBSD/rust-bootstrap-dragonfly#3) Yes, whatever you think it is easier for you. This repo is the initial bootstrap we had for Rust (created by @mneumann) but FreeBSD already has bootstrap ports and I think we should follow those. The problem is that we are really behind Ports so this repo will always make sense.

Recently, I tried compiling mrustc, a Rust compiler written in C++: https://github.com/thepowersgang/mrustc.git Its purpose is to serve as bootstrap compiler for rustc and builds out of the box on DragonFly (in 5 minutes on my old laptop). I think, it's time to use it instead of depending on the binary bootstrap.

…

-- Reply to this email directly or view it on GitHub: #3 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[lileding]

On Tue, Jun 23, 2026 at 01:34:58PM -0700, Antonio Huete Jimenez wrote: tuxillo left a comment (DragonFlyBSD/rust-bootstrap-dragonfly#3) Yes, whatever you think it is easier for you. This repo is the initial bootstrap we had for Rust (created by @mneumann) but FreeBSD already has bootstrap ports and I think we should follow those. The problem is that we are really behind Ports so this repo will always make sense.
Recently, I tried compiling mrustc, a Rust compiler written in C++: https://github.com/thepowersgang/mrustc.git Its purpose is to serve as bootstrap compiler for rustc and builds out of the box on DragonFly (in 5 minutes on my old laptop). I think, it's time to use it instead of depending on the binary bootstrap.
…
-- Reply to this email directly or view it on GitHub: #3 (comment) You are receiving this because you were mentioned. Message ID: @.***>

mrustc is definitely interesting as a seed/recovery bootstrap path.

However, I do not think it can replace the normal release-to-release Rust bootstrap chain. rustc keeps using new Rust language and library features, so in practice the compiler guaranteed to build release N+1 is release N. If a fixed older bootstrap compiler were enough, Rust could probably use a Go-style bootstrap model already.

So I think mrustc is worth testing separately to create an initial DragonFly Rust toolchain, but the regular path should still be Rust N building Rust N+1, with tests at each step.

[mneumann]

On Thu, Jun 25, 2026 at 07:13:50AM -0700, Leding Li wrote: lileding left a comment (DragonFlyBSD/rust-bootstrap-dragonfly#3) > On Tue, Jun 23, 2026 at 01:34:58PM -0700, Antonio Huete Jimenez wrote: tuxillo left a comment ([DragonFlyBSD/rust-bootstrap-dragonfly#3](#3)) Yes, whatever you think it is easier for you. This repo is the initial bootstrap we had for Rust (created by @mneumann) but FreeBSD already has bootstrap ports and I think we should follow those. The problem is that we are really behind Ports so this repo will always make sense. > Recently, I tried compiling mrustc, a Rust compiler written in C++: https://github.com/thepowersgang/mrustc.git Its purpose is to serve as bootstrap compiler for rustc and builds out of the box on DragonFly (in 5 minutes on my old laptop). I think, it's time to use it instead of depending on the binary bootstrap. > […](#) > -- Reply to this email directly or view it on GitHub: [#3 (comment)](#3 (comment)) You are receiving this because you were mentioned. Message ID: ***@***.***> mrustc is definitely interesting as a seed/recovery bootstrap path. However, I do not think it can replace the normal release-to-release Rust bootstrap chain. rustc keeps using new Rust language and library features, so in practice the compiler guaranteed to build release N+1 is release N. If a fixed older bootstrap compiler were enough, Rust could probably use a Go-style bootstrap model already.

I thought the Rust bootstrap process is as follows: stage0 is the binary bootstrap Rust compiler of version N. stage1 is Rust N+1 built by the binary bootstrap. stage2 is Rust N+1 built by the stage1 compiler (N+1). With mrustc this would become: stage0 is the mrustc compiler of Rust version N compiled using C++. stage1 is Rust N+1 built by the mrustc stage0 stage2 is Rust N+1 built by stage1 (N+1). Please correct me if I am wrong.

So I think mrustc is worth testing separately to create an initial DragonFly Rust toolchain, but the regular path should still be Rust N building Rust N+1, with tests at each step.

Isn't Gentoo using mrustc for "from source" bootstrapping?

…

-- Reply to this email directly or view it on GitHub: #3 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[lileding]

On Thu, Jun 25, 2026 at 07:13:50AM -0700, Leding Li wrote: lileding left a comment (DragonFlyBSD/rust-bootstrap-dragonfly#3) > On Tue, Jun 23, 2026 at 01:34:58PM -0700, Antonio Huete Jimenez wrote: tuxillo left a comment ([DragonFlyBSD/rust-bootstrap-dragonfly#3](#3)) Yes, whatever you think it is easier for you. This repo is the initial bootstrap we had for Rust (created by @mneumann) but FreeBSD already has bootstrap ports and I think we should follow those. The problem is that we are really behind Ports so this repo will always make sense. > Recently, I tried compiling mrustc, a Rust compiler written in C++: https://github.com/thepowersgang/mrustc.git Its purpose is to serve as bootstrap compiler for rustc and builds out of the box on DragonFly (in 5 minutes on my old laptop). I think, it's time to use it instead of depending on the binary bootstrap. > … > -- Reply to this email directly or view it on GitHub: [#3 (comment)](#3 (comment)) You are receiving this because you were mentioned. Message ID: @.> mrustc is definitely interesting as a seed/recovery bootstrap path. However, I do not think it can replace the normal release-to-release Rust bootstrap chain. rustc keeps using new Rust language and library features, so in practice the compiler guaranteed to build release N+1 is release N. If a fixed older bootstrap compiler were enough, Rust could probably use a Go-style bootstrap model already.
I thought the Rust bootstrap process is as follows: stage0 is the binary bootstrap Rust compiler of version N. stage1 is Rust N+1 built by the binary bootstrap. stage2 is Rust N+1 built by the stage1 compiler (N+1). With mrustc this would become: stage0 is the mrustc compiler of Rust version N compiled using C++. stage1 is Rust N+1 built by the mrustc stage0 stage2 is Rust N+1 built by stage1 (N+1). Please correct me if I am wrong.
So I think mrustc is worth testing separately to create an initial DragonFly Rust toolchain, but the regular path should still be Rust N building Rust N+1, with tests at each step.
Isn't Gentoo using mrustc for "from source" bootstrapping?
…
-- Reply to this email directly or view it on GitHub: #3 (comment) You are receiving this because you were mentioned. Message ID: @.>

Your stage model is basically correct, with one important detail: with mrustc,
mrustc first has to produce a usable Rust stage0 toolchain for a specific Rust
version. It is not a stable substitute for every future stage0.

The hard part is that rustc source keeps using new Rust language/library
features. For a normal release, the compiler intended to build N+1 is N, as
specified by Rust's stage0 data.

I rechecked Gentoo as well. The current regular Gentoo path is not mrustc:
dev-lang/rust uses an installed slotted Rust provider, either dev-lang/rust or
dev-lang/rust-bin, to build the next Rust release. Gentoo has had an
mrustc-bootstrap path around Rust 1.90, but that is a special source-bootstrap
path, not the normal per-release bootstrap chain.

[lileding]

Hi @tuxillo, just checking whether there is anything I should change on my side for this PR. No rush at all. I have also finished 1.96.0 locally, so this can wait until after Spain beats Portugal.