The Mold linker — the high-performance alternative to GNU Gold, GNU LD and LLVM LLD — has reached version 3.0, according to coverage from Phoronix. The milestone is notable less for any single changelog entry than for what it represents: the project's long-running rewrite from C++ to Rust has now produced a numbered, stable release, and the version number is the clearest signal yet that the migration is advancing beyond experimental territory.
Mold's ambitions extend past its own benchmarks. The project has stated its eventual aim of becoming the default linker on Linux systems — a claim to be read as a roadmap item rather than an installed-base fact. But even short of that goal, a stable post-rewrite release gives teams a concrete data point for where the linker stands today, and Phoronix's framing positions 3.0 as a serious contender in the GNU/LLVM linker ecosystem rather than a niche curiosity.
For engineering teams running large build matrices on cloud CI, the practical question is what this means for compile-and-link times. Linking is frequently the slowest stage in a monolithic C or C++ build, and it scales poorly because most linkers do comparatively little of it in parallel. Mold was designed around that gap — distributing link-time work across available cores — so its headline value proposition is wall-clock reduction in builds that previously idled while one process chewed through relocations.
That proposition is why the release lands squarely in CI/CD budgets rather than only in developer workstation preferences. A project that links thousands of translation units per build can see total pipeline duration dominated by the final link step; shaving that down translates directly into faster merge pipelines, quicker feedback loops, and, where builds are metered by the minute, lower cloud spend. It is the kind of saving that compounds across daily runs rather than appearing as a one-off gain.
That said, the framing matters. Version 3.0 is best read as an incremental milestone rather than the finish line of the Rust migration. Rewrites of this scale typically land in stages — module by module, subsystem by subsystem — and a release cut does not necessarily mean every code path has been converted. Teams considering adoption should check the release notes against their own toolchain configuration to confirm that the code paths their builds exercise are covered, rather than assuming that a version bump implies a uniform outcome.
The same caution applies to performance claims. Phoronix's coverage of the project has generally reported Mold in a favourable light on benchmarked workloads, but linker performance is heavily workload-dependent: symbol counts, debug information volume, link-time optimization settings, and allocator behaviour all shift the numbers. The reliable move for any team evaluating the release is to benchmark it against their own repository, on their own CI runners, with their own toolchain flags — and to keep the previous linker pinned and switchable until regression suites pass.
There is a security rationale attached to the rewrite as well, though it should be attributed rather than treated as a proven outcome. The project has described Rust as eliminating an entire category of memory-safety bugs common in traditional C++ linkers — use-after-free, dangling references in symbol resolution, buffer errors in input parsing. If that claim holds in practice, it is meaningful for a component that sits in every build of a project. If it is only partially realised in 3.0, it is still directionally useful. Either way, the honest posture is to treat memory safety as a project goal being progressively realised, not as a guarantee shipped with this tag.
Practical availability details are the other item teams will need to confirm locally. The release is published through the project's own channels, but downstream packaging — whether in distribution repositories or in toolchain managers such as Homebrew on macOS — can lag upstream tags by days or weeks, and platform support on Apple systems is a separate question from Linux linker coverage. Teams should verify current availability against the project's release page and their package manager before adjusting pipeline images.
For IT organisations with large C and C++ codebases, none of this is a reason to hold back. Major toolchain updates deserve standard diligence — pin versions, run the full regression suite, compare before-and-after timings on your own builds — but the combination of a stable numbered release, an ongoing Rust migration with a stated default-linker ambition, and the CI economics of faster linking makes 3.0 a sensible candidate for the next evaluation window rather than a fork in the road.
Source: Phoronix, "Mold 3.0 High Speed Linker Released Following Rust Rewrite."
據 Phoronix 報導，高性能 linker 替代方案 Mold —— 作為 GNU Gold、GNU LD 及 LLVM LLD 的高性能替代品 —— 已經推出 3.0 版本。這個里程碑的重要性，與其說在於 changelog 中任何單一條目，不如說在於它所代表的意義：項目長期進行的由 C++ 轉寫 Rust 的工程，如今已產出一個有正式版本號的穩定版本，而版本號本身正是迄今最清晰的信號，顯示遷移已超越實驗階段，持續推進。
Mold 的野心並不止於其自身的 benchmark 數據。項目已表明最終目標是成為 Linux 系統上的預設 linker —— 這一聲明應理解為路線圖項目，而非現有裝機量的事實。但即使尚未達到這一目標，一個轉寫後的穩定版本，也為團隊提供了關於該 linker 目前水平的具體數據點；而 Phoronix 的定位亦將 3.0 列為 GNU／LLVM linker 生態中的有力競爭者，而非僅供一小撮愛好者好奇的邊緣工具。
對於在雲端 CI 上運行大規模 build matrix 的工程團隊而言，實際問題是：這對 compile 及 link 時間意味著甚麼。Linking 通常是整體式 C 或 C++ build 中最慢的一個階段，而且擴展性欠佳，因為大多數 linker 在並行處理方面的程度相對有限。Mold 正是針對這一缺口而設計 —— 將 link 階段的工作分散到各個可用核心 —— 因此其核心價值主張，是減少那些原本因單一 process 逐一處理 relocation 而處於閒置狀態的 build 的實際耗時。
正因如此，此次發布直接影響的是 CI/CD 的開支預算，而不只是開發者工作站上的個人偏好。一個每次 build 需要 link 數千個 translation units 的項目，其 pipeline 的總耗時往往由最後的 link 步驟主導；縮減這一步，可直接轉化為更快的 merge pipeline、更快的反饋循環，以及在 build 按分鐘計費的情況下更低的雲端開支。這是那種會在每日例行運行中不斷累積的節省，而非一次性的收益。
話雖如此，如何理解這件事仍有講究。3.0 版本最好視為一個漸進式的里程碑，而非 Rust 遷移的終點線。這種規模的轉寫工程通常分階段落地 —— 逐個 module、逐個 subsystem —— 而一個正式發布版本，未必代表每條 code path 都已完成轉換。考慮採用的團隊應將 release notes 與自身 toolchain 配置逐一對照，確認其 build 實際用到的 code path 是否已涵蓋，而不應假設版本號的提升就等同於全面一致的結果。
同樣的審慎態度亦適用於性能宣稱。Phoronix 對該項目的報導，一般在 benchmark 工作負載下對 Mold 呈現正面評價，但 linker 的性能高度取決於具體工作負載：symbol 數量、debug information 的體積、link-time optimization 設定以及 allocator 的行為，都會影響數字的高低。任何團隊評估此版本時，最可靠的做法是在自己的 repository、自己的 CI runner 及自己的 toolchain flags 上與之進行 benchmark —— 並在回歸測試套件通過之前，保留原本的 linker 並確保可以隨時切換。
這次轉寫亦有其安全層面的理據，不過應如實歸因，而不能視為已獲證實的成果。項目方面表示，Rust 可以消除傳統 C++ linker 中常見的一整類 memory-safe bug —— 包括 use-after-free、symbol resolution 中的 dangling references，以及輸入解析時的 buffer 錯誤。如果這一宣稱在實踐中成立，對於一個存在於每一個項目 build 中的元件而言意義重大。即使在 3.0 中只實現了一部分，它仍具方向性的參考價值。無論如何，最誠實的態度是將 memory safety 視為一個正在逐步實現的項目目標，而非隨此版本號一同交付的保證。
實際可用性方面的細節，則是團隊需要在本地環境確認的另一項事項。此版本通過項目自身的渠道發佈，但下游打包 —— 無論是發行版 repositories 還是 macOS 上 Homebrew 等 toolchain manager —— 可能較上游 tag 滯後數日甚至數星期；而 Apple 平台上的支援狀況，則與 Linux linker 的涵蓋範圍是兩個獨立的問題。團隊在調整 pipeline image 之前，應先查閱項目 release page 及自身的 package manager，核實當前的可用性。
對於擁有大型 C 及 C++ codebase 的 IT 機構而言，以上種種都不是猶豫不決的理由。重大 toolchain 更新理應接受標準審慎程序 —— 鎖定版本、運行完整回歸測試套件、在自己的 build 上比較更新前後的耗時 —— 但穩定的正式版本號、持續進行且已明言預設 linker 野心的 Rust 遷移，再加上更快 linking 帶來的 CI 成本效益，三者結合使 3.0 成為下一個評估窗口中合理的候選方案，而不是一條令人卻步的分岔路。
來源：Phoronix，《Mold 3.0 High Speed Linker Released Following Rust Rewrite》