Mold 3.0 publie sa réécriture en Rust, un éditeur de liens à remplacement direct

Mold 3.0, la première version écrite en Rust de cet éditeur de liens rapide pour Linux, est sortie le 5 octobre 2026. Son auteur, Rui Ueyama, a réécrit tout le programme à partir du C++. Les notes de version promettent un remplacement sans accroc : les mêmes options, la même sortie et la même vitesse que mold 2.42.1, la dernière version en C++. C'est important, car mold veut désormais devenir l'éditeur de liens par défaut sous Linux.

Ce que fait un éditeur de liens et la place de mold

Un éditeur de liens est la dernière étape de la construction d'un programme. Le compilateur transforme chaque fichier source en fichier objet. L'éditeur de liens assemble ensuite ces morceaux en un seul programme exécutable. Sur de gros projets, cette étape peut prendre de nombreuses secondes, et elle se relance après chaque petite modification.

La plupart des systèmes Linux utilisent par défaut GNU ld, l'éditeur de liens du projet GNU. Le lld de LLVM est une alternative plus rapide. Mold a été conçu pour battre les deux. Son dépôt indique ces temps d'édition de liens, issus de tests menés en août 2026 :

Programme	mold	LLVM lld	Accélération
Chromium 145	1,65 s	16,64 s	10,1x
TensorFlow 2.21	3,15 s	50,73 s	16,1x
ClickHouse 26.1	0,98 s	6,62 s	6,7x

Ces chiffres ont été mesurés sur la version C++. Les notes de la version 3.0 indiquent que la vitesse d'édition de liens « reste au niveau de 2.42.1 », la version Rust revendique donc les mêmes résultats. Ueyama avait présenté le projet pour la première fois en septembre : La réécriture de mold en Rust vise l'éditeur de liens par défaut de Linux.

Ce qui change dans mold 3.0

Pour qui se contente d'appeler mold, rien ne devrait sembler différent. Selon les notes de version sur GitHub et Phoronix, mold 3.0 :

• accepte les mêmes options de ligne de commande que 2.42.1
• prend en charge les mêmes architectures de processeur, dont x86-64, AArch64, RISC-V et LoongArch
• produit la même sortie, sauf là où des bogues ont été corrigés
• établit les liens à la même vitesse que 2.42.1

Les vrais changements concernent la façon dont mold lui-même est construit. Il utilise désormais Cargo, l'outil de construction standard de Rust, à la place de CMake. Sa compilation exige Rust 1.95 ou une version ultérieure.

Il abandonne aussi oneTBB, une bibliothèque d'Intel qui répartit le travail entre les cœurs du processeur. C'était un paquet de plus que les distributions Linux devaient livrer à côté de mold.

Pourquoi réécrire en Rust un éditeur de liens qui fonctionne

La raison principale est la sûreté. Un éditeur de liens lit des fichiers objets qu'il n'a pas créés. Il effectue ensuite sur eux un important travail de bas niveau en mémoire.

En C++, un seul fichier d'entrée défectueux peut amener ce code à lire une zone mémoire qu'il ne devrait jamais toucher. Hardware Busters a rapporté en septembre que c'est précisément là qu'un bogue mémoire devient une faille de sécurité. Rust vérifie ces lectures automatiquement. Selon Phoronix, mold est donc désormais plus sûr lorsqu'il traite des fichiers d'entrée corrompus.

La suite : scripts d'édition de liens et place par défaut

La série 3.x a un objectif clair. Le but affiché du projet est de « combler les derniers écarts de compatibilité avec GNU ld, en particulier dans la prise en charge des scripts d'édition de liens ». Il veut aussi « ouvrir la voie à l'adoption de mold comme éditeur de liens par défaut dans les distributions Linux ».

Les scripts d'édition de liens sont de petits fichiers qui indiquent à un éditeur de liens exactement où placer le code en mémoire. Les noyaux de systèmes d'exploitation, les chargeurs d'amorçage et le micrologiciel des petits appareils en dépendent. Mold ne pouvait pas lier ces programmes jusqu'ici, a rapporté Hardware Busters. Tant qu'il n'en sera pas capable, les distributions ne pourront pas en faire l'outil par défaut du système.

Ce que cela signifie pour les développeurs

Traitez 3.0 comme un remplacement direct, puis vérifiez. Si vous utilisez déjà mold, vos options de compilation ne devraient pas avoir à changer. Liez d'abord un vrai projet avec 2.42.1 et avec 3.0. Lancez ensuite toute votre suite de tests avant de basculer vos machines d'intégration continue.

Vérifiez votre compilateur si vous compilez mold vous-même. Rust 1.95 ou une version ultérieure est requis, donc le Rust plus ancien fourni par certaines distributions à support long risque de ne pas suffire à le compiler. Les empaqueteurs perdent la dépendance à oneTBB, mais héritent d'une construction avec Cargo.

Mesurez vos propres temps d'édition de liens. Les accélérations du tableau proviennent du propre dépôt de mold, et elles ont été mesurées avant la réécriture. Chronométrez une compilation complète et une petite recompilation incrémentale sur votre propre code, avant et après le changement.

Surveillez les distributions. Si une grande distribution fait de mold son éditeur de liens par défaut, chaque compilation sur ce système l'utilisera sans que personne ne le demande. Cette décision dépend désormais de la prise en charge des scripts d'édition de liens dans la série 3.x. Les développeurs de noyaux et de systèmes embarqués sont le groupe à suivre en premier.