Hacker News Reader

Comment by aseipp | Hacker News Reader

Can't you just keep using Mold2 for the initial toolchain bootstrap and then build mold3 with Rust as part of the "final" set of toolchains that are to be used to compile everything beyond that? It isn't perfect but it's congruent with how many other components in most open reproducible bootstrapping flows work; ie using GCC 4.4 or whatever just to bootstrap GCC 10. It's annoying but it only needs to be done once and then you just use it to bootstrap newer components forever. Doesn't help with compile times, though.

View on HN

I would agree if not for the fact rust depends on almost the entire tree, so doing what you propose would increase our full tree verification time from 6ish hours to 12ish hours erasing any wins mold was giving us in the first place.

why can't you do:

C/C++ + libc ↓ LLVM/LLD ↓ mrustc + minicargo ↓ rustc 1.90 Cargo 1.90 ──→ OpenSSL ↓ Python x.py ↓ Rust 1.91+

That is what we do, and it takes several hours on most machines. Having to do that once to get mold and a second time to then build with the benefits of mold defeats any advantages for us.

I may be misinterpreting the parents point, but you're not building E.g. tinycc for it to be a final artefact; why not continue to build mold2 in its current place in the build chain? It's not going anywhere, much like tinycc isn't.

We have to rebuild tinycc any time a dependency of tinycc changes. Likewise we would have to rebuild mold every time a dependency of mold changes, including rust and all dependencies of rust. It is a problem of almost full tree dependency recursion.

Yes. I'm saying that mold3 gets added to the end of the build tree, and mold2 remains where it is currently, which doesn't change how often you need to build those and let's you continue to use mold2 to speed up the builds (which I've now seen is what you'll likely do).

My point though was that you already build many end-of-life projects just so they can be used in the build, mold2 can now one of those rather than being built for its use in the final distro.

Frozen code seems even better for this use case.

I indicated as much in my original comments. Pinning mold2 and backporting relevant fixes to it forever is our responsibility now that upstream has abandoned the linux-distro-bootstrapping use case. It is just unfortunate as that was supposed to be one of the goals.

Reply on news.ycombinator.com