Molds Rust-Neufassung will Linux' Standard-Linker werden
Mold linkt laut eigenem Repository 4,9-mal schneller als LLVM lld. Sein Autor schreibt das Werkzeug in Rust neu und will, dass Distributionen es als /usr/bin/ld installieren.
Von Claire Whitmore
4 Min. Lesezeit
Maschinell übersetzt aus dem englischen Original, das Claire Whitmore auf Fakten geprüft und redigiert hat. Es gilt die englische Fassung. So arbeiten wir

Die Zahlen
- CPU architectures mold supports
- 14
- contributors to the mold project
- 140+
- commits on mold's main branch
- 7,853
- vs LLVM lld
- 4.9x
- vs wild
- 1.9x
Rui Ueyama schreibt mold von C++ nach Rust um. Mold ist einer der schnellsten Linker, die es unter Linux gibt. Phoronix berichtete am 11. September 2026, dass diese Neufassung den Kern der kommenden 3.x-Reihe bildet. Das zweite Ziel sollten Entwickler im Auge behalten: mold möchte, dass Linux-Distributionen es als /usr/bin/ld installieren, den Standard-Linker, zu dem jeder Build greift.
Ein Linker ist der letzte Schritt eines Builds. Der Compiler macht aus jeder Quelldatei eine Objektdatei. Der Linker fügt diese Objekte und ihre Bibliotheken dann zu einem lauffähigen Programm zusammen. Bei einem großen C++- oder Rust-Projekt entscheidet dieser letzte Schritt oft über die Wartezeit.
Der Unterschied ist groß. Phoronix beschrieb ihn mit konkreten Zahlen. Ein Link-Vorgang, den mold in „ein paar hundert Millisekunden“ erledigt, kann „mehrere Sekunden, Dutzende Sekunden oder sogar Minuten mit dem Standard-Linker“ dauern.
Das mold-Repository gibt an, im Median 4,9-mal schneller zu linken als LLVMs lld und 1,9-mal schneller als wild. Ueyama hat auch lld geschrieben, er tritt also gegen seine eigene frühere Arbeit an. Das Projekt ist seit 2021 im produktiven Einsatz. Es unterstützt 14 CPU-Architekturen, darunter x86-64, ARM, RISC-V, PowerPC, s390x, LoongArch und SPARC64.
Warum Rust, und warum jetzt
Ueyama nannte seine Gründe in einer angehefteten Diskussion im GitHub-Repository von mold, die am 1. September 2026 begann. Speichersicherheit stand an erster Stelle. Ein Linker liest Objektdateien, die er nicht selbst erzeugt hat, und rechnet viel mit Zeigern. Genau dort ist ein Speicherfehler leicht geschrieben und schwer zu finden.
Er verwies außerdem auf das Werkzeug-Umfeld. Rust bringt Cargo für die Verwaltung von Abhängigkeiten mit und vereinfacht das Cross-Compiling. Beides zählt für ein Werkzeug, das für 14 Architekturen gebaut werden muss. C++20, molds aktuelle Sprache, bietet ihm von Haus aus keines von beidem.
Über das Zeitargument wird am meisten gestritten werden. Ueyama schreibt es KI-gestützten Programmierwerkzeugen zu, dass die Neufassung überhaupt bezahlbar wurde. „KI-gestütztes Umschreiben hat die Kosten für diese Art von Arbeit drastisch verändert“, schrieb er. „Letztes Jahr hätte ich es vermutlich nicht versucht, aber heute kostet es erstaunlich wenig Mühe.“
Er bezeichnete die Entscheidung als langfristige Wette: „Diese Entscheidung wird im Rückblick in 10 oder 20 Jahren mehr Sinn ergeben, als sie es heute vielleicht tut.“
Andere Projekte sind dieses Jahr denselben Weg gegangen. Bun 1.4 brachte seine Rust-Neufassung in den Produktivbetrieb, und bei YSERVER 1.5, einem von Grund auf in Rust geschriebenen X11-Server, entstand der frühe Code mit KI-Hilfe.
/usr/bin/ld zu werden ist die schwerere Hälfte
Geschwindigkeit ist nicht das, was einen Linker davon abhält, zum Standard zu werden. Kompatibilität ist es. GNU ld und sein schnelleres Geschwisterprojekt gold haben über Jahrzehnte Verhalten angesammelt, auf das sich Build-Skripte stillschweigend verlassen. Das reicht von der Syntax der Linker-Skripte bis zu obskuren Kommandozeilen-Optionen.
Das Projekt weiß das. „Eines der Hauptziele der mold-3.x-Reihe ist es, mold für die Übernahme als /usr/bin/ld durch Linux-Distributionen geeignet zu machen“, berichtete Phoronix. Der Plan nach der Neufassung ist langsam und auf Zusammenarbeit angelegt: „Wir werden dann umfangreiche Kompatibilitätstests durchführen und eng mit den Entwicklern der Linux-Distributionen zusammenarbeiten.“
| Schritt | Status |
|---|---|
| mold von C++ nach Rust umschreiben | Läuft, Ziel ist die 3.x-Reihe |
| Umfangreiche Kompatibilitätstests | Geplant, nach der Neufassung |
| Abstimmung mit Distributions-Entwicklern | Geplant, nach den Tests |
Auslieferung als /usr/bin/ld | Nicht terminiert |
Keine Distribution hat sich zum Wechsel verpflichtet. Für keinen dieser Schritte wurde ein Datum genannt.
Der erste Schritt ist inzwischen erledigt. Mold 3.0, die erste Rust-Version, erschien am 5. Oktober 2026: Mold 3.0 liefert den Rust-Neubau als Drop-in-Linker.
Was das für Entwickler bedeutet
Heute geht nichts kaputt. mold 2.x bleibt, wie es ist, und die Rust-Neufassung landet in einer künftigen 3.x-Reihe ohne Veröffentlichungstermin.
Wenn Sie mold noch nie ausprobiert haben, ist diese Woche ein guter Zeitpunkt, den möglichen Zeitgewinn zu messen. Auf einer Linux-Toolchain können Sie einen einzelnen Build mit -fuse-ld=mold darauf umstellen. Vergleichen Sie dann den Link-Schritt mit Ihrem bisherigen Standard. Projekte mit vielen Objektdateien und großen statischen Bibliotheken sehen den größten Unterschied; ein kleines Projekt sieht womöglich gar keinen.
Wenn Sie ein Build-System oder ein Distributionspaket pflegen, ist die Kompatibilitätsphase der Punkt, an dem Ihr Beitrag zählt. Eigene Linker-Skripte, ungewöhnliche Optionen und Einstellungen zur Link-Time-Optimierung weichen am ehesten ab. Ueyama hat ausdrücklich gesagt, dass er Distributions-Entwickler einbeziehen will, bevor sich irgendein Standard ändert.
Hier gibt es noch einen zweiten Punkt, unabhängig von Linkern. Der Betreuer eines weit verbreiteten Systemwerkzeugs hat nun öffentlich gesagt, dass KI-Unterstützung verändert hat, welche Neufassung er sich zutraute. Ob dieses Urteil Bestand hat, wird die 3.x-Reihe im Code beantworten. Man sollte es am Ergebnis prüfen, nicht an der Behauptung.
Quellen
Ähnliche Artikel

Mold 3.0 liefert den Rust-Neubau als Drop-in-Linker
Mold 3.0 ist die erste in Rust geschriebene Version. Sie braucht Rust 1.95, verzichtet auf Intels oneTBB und linkt so schnell wie 2.42.1, die letzte C++-Version.

COSMIC Epoch 1.11 bringt xdg-dialog-v1 und Fixes für Hybrid-GPUs
COSMIC Epoch 1.11 hält modale Dialoge mit Waylands xdg-dialog-v1 im Vordergrund und schickt Spiele auf Hybrid-Laptops auf die richtige GPU, 12 Tage nach 1.10.

YSERVER 1.7 bringt Vulkan 1.2 und senkt den VRAM-Bedarf in 4K
YSERVER 1.7 senkt den VRAM-Bedarf in 4K von 2-4 GB auf etwa 1,2 GB, nahe an den 0,9 GB von X.Org, und ergänzt Vulkan-1.2-Unterstützung für ältere Intel-Grafik.