rui314

Rust Toolchain Migration: Supercharging Build Times with LLD on Windows Recently, driven by the need to slash compilation and linking times, I migrated the toolchain for my pet Rust project. Previously, the project relied on the battle-tested stable-x86_64-pc-windows-gnu toolchain using the legacy ld linker—a notorious bottleneck responsible for much of Rust's sluggish build reputation on Windows. While the speed payoff of switching to the lld linker was immediate, the transition exposed a labyrinth of subtle, platform-specific hurdles on Windows. Before diving into the migration details, let’s quickly break down the anatomy of how Rust compiles code. !Image description Under the Hood: The Rust Compilation Pipeline If you trace a Rust file from source text to binary, it moves through several sophisticated stages: AST (Abstract Syntax Tree): rustc parses the source code into an AST, where macros are expanded. HIR (High-Level Intermediate Representation): The AST translates into HIR. This is where Rust’s borrow checker flexes its muscles, enforcing memory safety and ownership rules. MIR (Mid-Level Intermediate Representation): The HIR simplifies into MIR, marking the end of rustc's proprietary heavy lifting. LLVM Optimization: The pipeline hands off to the LLVM infrastructure. MIR is translated into platform-agnostic bitcode, where LLVM applies State-Of-The-Art (SOTA) optimizations. (LLVM’s power is precisely why Apple, Google, and massive Linux/Windows ecosystems rely on it). Code Generation & Linking: LLVM generates machine code for specific target architectures, after which linkers bundle system and third-party libraries into the final executable. The Windows Toolchain Maze: GNU vs. GnuLLVM While Rust packages essential LLVM components out of the box, target-specific concerns—like operating system interfaces, C calling conventions, and ABIs—are bound to external packages. The GNU Target (stable-x86_64-pc-windows-gnu): Simply requires MinGW-W64-builds to complete the toolchain pipeline. The GnuLLVM Target (stable-x86_64-pc-windows-gnullvm): Requires standalone LLVM and llvm-mingw. Navigating llvm-mingw can be jarring due to the sheer volume of overlapping binaries. Essentially, stock LLVM builds provide target-agnostic components that aren't inherently tied to MSVC or GNU C conventions. llvm-mingw bridges this gap, translating raw machine code into standard MinGW-compatible formats that Windows can execute. Lessons Learned from the Trenches Taming Windows toolchains is famously painful. It's the primary reason many developers flee to environments like MSYS2 or Windows Subsystem for Linux (WSL). However, because my pet project is a GUI application, native Windows integration is a must, and WSL's graphical UI maturity still introduces friction for native desktop apps. The Golden Rule: Infrastructure upgrades like compiler toolchains should always be treated with extreme caution. Rigorous staging and testing are non-negotiable—never perform radical toolchain experiments blindly in production environments. Bonus: Alternative Paths to Speed If you want to tap into lld's blazing speed without undergoing a full toolchain migration, you can adopt it simply by changing some settings of your projects. Modern alternatives are pushing the boundaries of link-time performance even further. If you are feeling adventurous, check out these next-gen linkers built by hard-core pioneers: mold — A high-performance, modern linker designed to drastically reduce build times. wild — An experimental, incredibly fast linker written in Rust.

Mold linker hits 3.0 with a complete Rust rewrite. A critical build tool choosing memory safety over C++ signals broader ecosystem shifts in systems software. github.com/rui314/mold/releases/tag/v3.0.0 #opensource #Linux

hey guys I made mold faster mold#1718 t.co

I did an analysis of where time is going in `mold` in my PR, which is close enough to the current state of `main` anyway mold#1696

Mold linker 3.0.0: now rewritten in Rust The Mold high-speed linker has released version 3.0.0, completely rewritten from C++ to Rust, superseding 2.42.1. This rewrite aims to make it a default linker in Linux distros, a significant step for core infrastructure.

The author mentions using AI for doing the port.

🦠 Mold: A high-performance drop-in replacement for existing Unix Linkers - Rewritten from C++ to Rust rui314/mold t.co

@syrusakbary My plan is to eventually merge this into mold: rui314/mold-macho

Apparently the old mold version had a couple of plain C source files in the source tree (both vendored 3rd party libs but also in the 'regular' source code), so technically C/C++ is correct in this case ...and looks like the Rust version also has some (very minimal) C code left (looks like mostly varargs stuff, I guess Rust doesn't have a concept of varargs?), so it could be called a C/Rust project ;) github.com/rui314/mold/tree/main/c

mold is one of the first things I install on all distros already, so this makes me even happier to use it github.com/rui314/mold/releases/tag/v3.0.0