Molds Rust-Neufassung will Linux' Standard-Linker werden

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.

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.