mold 3.0: Rust und Cargo ändern den Linker-Selbstbau

Wer mold selbst für Linux-Buildserver oder CI-Images paketiert, muss vor dem Wechsel auf Version 3.0.0 die Werkzeugkette anpassen: Cargo ersetzt CMake, erforderlich sind Rust ab 1.95 und ein C-Compiler. Ein geplantes Upgrade mit geprüften Buildskripten ist angemessen, kein pauschales Notfallupdate. Systeme ohne mold und Umgebungen, die ausschließlich fertige Programme ausführen, benötigen wegen dieses Releases keine neue Rust-Werkzeugkette.

Der am 5. Oktober 2026 veröffentlichte Linker ist erstmals in Rust statt C++ implementiert. Version 2.42.1 bleibt laut Projekt die letzte C++-Ausgabe. Für Teams, die fertige mold-Binärpakete beziehen, liegt der Schwerpunkt dagegen auf Paketverfügbarkeit und dem Vergleich eigener Build-Ergebnisse. Der Wechsel der Implementierungssprache betrifft nicht automatisch die Sprache der damit gebauten Anwendungen.

Neuer Unterbau, vertraute Linker-Schnittstelle

mold verbindet Objektdateien zu ausführbaren Dateien oder gemeinsamen Bibliotheken. Das Projekt positioniert 3.0 als direkten Ersatz für 2.42.1: Kommandozeilenoptionen, Zielarchitekturen und Ausgabe sollen, abgesehen von den dokumentierten Fehlerkorrekturen, gleich bleiben. Auch die Link-Leistung bezeichnet das Projekt als vergleichbar. Das sind Angaben der Entwickler, keine hier unabhängig gemessenen Ergebnisse.

Zur Absicherung nennt das Projekt Tests auf allen unterstützten Zielen, Vergleiche mit realen Arbeitslasten und den Bau sämtlicher Gentoo-Pakete. Dabei seien keine Regressionen gefunden worden. Diese breite Prüfung ersetzt dennoch nicht die Freigabe kundenspezifischer Linkerskripte. Verbleibende Kompatibilitätslücken zu GNU ld, besonders bei Linkerskripten, zu schließen, ist ausdrücklich ein Ziel der 3.x-Reihe und keine bereits vollständig erreichte Eigenschaft.

Was sich beim Selbstbau tatsächlich ändert

Die Release-Notes und die README des Tags v3.0.0 bestätigen die neuen Voraussetzungen. Alte CMake-Aufrufe lassen sich deshalb nicht unverändert in neue Paketrezepte übernehmen. Die dokumentierten Änderungen betreffen mehrere Stellen:

• Der Release-Build läuft über cargo build --release; Rust 1.95 oder neuer und ein C-Compiler müssen im Build-Image verfügbar sein.
• Die Installation übernimmt install-mold.sh, das die Variablen PREFIX und DESTDIR akzeptiert.
• Frühere CMake-Optionen entfallen. Die Auswahl der Zielarchitekturen erfolgt nun über Cargo-Features; Distributionen sollen weiterhin alle Ziele bauen.
• Die Abhängigkeit von oneTBB entfällt. mimalloc 3.5.3 wird weiterhin standardmäßig statisch eingebunden; alternativ steht das Feature system-allocator bereit.
• Bei einem abweichenden Bibliotheksverzeichnis wie /usr/lib64 muss MOLD_LIBDIR beim Bau und bei der Installation gleich gesetzt werden, damit mold -run die Wrapper-Bibliothek findet.
• Die Projekttests wechseln von ctest zu cargo test. Das neue Skript install-test-deps.sh wird laut Projekt nur für diese Tests benötigt.

Korrekturen schützen Build-Ergebnisse

Neben dem Sprachwechsel korrigiert 3.0 zahlreiche Fehler, die für reproduzierbare Pakete wichtig sind. Ein Absturz beim Erzeugen statisch gelinkter Programme mit Versionsskript oder --default-symver ist behoben. Ebenso wurde der Fall korrigiert, bei dem dieselbe Datei gleichzeitig Eingabe und Ausgabe war und dadurch Abstürze oder beschädigte Ergebnisse entstanden.

Weitere Korrekturen betreffen nichtdeterministische Ausgaben bei --dependency-file, --repro sowie bestimmten Gruppen und dynamischen Relokationen. Funktionen, die über --init oder --fini angegeben werden, entfernt --gc-sections nicht mehr. Bestimmte unzulässige Kombinationen erzeugen nun Fehler statt defekter Ausgaben. Für Paketverantwortliche ist deshalb auch das veränderte Fehlerverhalten relevant, nicht nur eine erfolgreich beendete Pipeline.

Rust verbessert Fehlergrenzen, garantiert aber keine Fehlerfreiheit

Bei beschädigten Eingabedateien konnte die C++-Implementierung außerhalb gültiger Speicherbereiche lesen und mit einem Segmentierungsfehler abbrechen. In 3.0 werden diese Zugriffe laut Projekt geprüft; mold beendet sich am fehlerhaften Zugriff mit einer Panic. Daraus folgt weder eine Garantie für fehlerfreie Eingaben noch eine allgemeine Sicherheitszusage. Die Meldung beschreibt ein Release mit Robustheitsverbesserungen, kein Advisory zu einer hier belegten aktiv ausgenutzten Schwachstelle.

Prioritäten für Entwicklungsbetrieb und Paketbau

• Zuerst installierte mold-Versionen und den Bezugsweg inventarisieren: selbst gebautes Werkzeug oder fertiges Distributionspaket.
• In eigenen CI-Images Rust-Version, Cargo, C-Compiler und verbliebene CMake-Annahmen vor der Umstellung überprüfen.
• Paketrezepte auf Zielauswahl, Installationspfade und konsistentes MOLD_LIBDIR abgleichen.
• Repräsentative Programme mit den tatsächlich genutzten Optionen vergleichen und neue Fehlermeldungen vor einer breiten Freigabe bewerten.
• Die bisherige Werkzeugversion für einen kontrollierten Rückweg verfügbar halten; eine konkrete Distributionsverfügbarkeit ergibt sich nicht allein aus dem GitHub-Release.

Passende Anleitungen auf S-EDV

• Jenkins als CI/CD-Server betreiben: Hintergrund zur Infrastruktur, in der eigene Compiler- und Linker-Images eingesetzt werden.
• Woodpecker CI und Container-Pipelines: Ergänzende Grundlage für die Organisation reproduzierbarer Buildabläufe.

Quellen

• Offizielle Release-Notes zu mold 3.0.0
• Projekt-README des Release-Tags mit Build-Voraussetzungen
• Linuxiac zur Rust- und Cargo-Umstellung