• by kimixa on 6/16/2025, 8:51:54 PM

    > Modern clang and gcc won't compile the LLVM used back then (C++ has changed too much)

    Is this due to changing default values for the standard used, and would be "fixed" by adding "std=xxx" to the CXXFLAGS?

    I've successfully built ~2011 era LLVM with no issues with the compiler itself (after that option change) using gcc last year - there were a couple of bugs in the llvm code though that I had to workaround (mainly relying on transitive includes from the standard library, or incorrect LLVM code that is detected by the newer compilers)

    One of the big pain points I have with c++ is the dogmatic support of "old" code, I'd argue to the current version's detriment. But because of that I've never had an issue with code version backwards compatibility.

  • by jasonthorsness on 6/16/2025, 8:44:20 PM

    The difficulty in reproducing builds and steps even from a time as recent as 2011 is somewhat disturbing; will technology stabilize or is this going to get even worse? At what point do we end up with something in-use that we can’t make anymore?

  • by LegionMammal978 on 6/16/2025, 10:00:30 PM

    I've done this project myself, based on Ubuntu 20.04 and a whole lot of patchsets [0]. I got up to the 2014-01-20 snapshot before running into weird LLVM stack issues that I couldn't figure out how to resolve. One big annoyance is that the snapshot file refers to some commit hashes that do not appear to point to any surviving public repo, so it takes a fair bit of effort to reconstruct which commits must have been included in the missing commits.

    [0] https://github.com/LegionMammal978/rust-from-ocaml

  • by tmtvl on 6/16/2025, 8:33:15 PM

    I believe Guix faced some issues in bootstrapping Rust (which ties in to the reproducible builds they want to do), there's an article about it from 2018: <https://guix.gnu.org/en/blog/2018/bootstrapping-rust/>.

  • by neilv on 6/16/2025, 10:33:10 PM

    Is there, or could there be, a simple implementation of a compiler for the latest full Rust language (in C, Python, Scheme/Racket, or anything except Rust) that is greatly simplified because, although it accepts the latest full Rust language as input, it assumes the input is correct?

    Could this simple non-checking Rust implementation transliterate the real Rust compiler's code, to unchecked C, that is good enough for that minimal-steps, sustainable bootstrapping?

    This simple non-checking compiler only has to be able to compile one program, and only under controlled conditions, possibly only on hardware with a ton of memory.

  • by gregorvand on 6/17/2025, 2:03:32 AM

    Why do I have to use a VPN and pick a US server to access this article?

  • by fcoury on 6/16/2025, 8:29:46 PM

    Not sure why, but I am getting 403 Forbidden, so if you are getting the same here's an archive.is link https://archive.is/UH5fg

  • by 15155 on 6/16/2025, 9:55:52 PM

    I imagine you just need to update CA certs and the known_hosts file to get GitHub communication working again.

  • by eptcyka on 6/16/2025, 9:55:57 PM

    Can’t say I’m a fan of Nix evangelists pointing their finger at any problem and yelling how it would be solved better by using Nix, but in this case, one could pin a nixpkgs version and all the sources for llvm, gcc and ocaml, and thus have a reproducible bootstrap. Ultimately, it wouldn’t do anything different to what was done manually here, but pinning commits will save the archaelogical burden for the next bootstrapper.

  • by neilv on 6/16/2025, 10:16:36 PM

    > Debian has maintained both EOL'ed docker images and still-functioning fetchable package archives at the same URLs as 14 years ago.

    Debian FTW.