Mold réécrit son éditeur de liens en Rust et vise le statut de linker par défaut de Linux
La version 2.42.1 de Mold, publiée le 11 septembre 2026, est la dernière écrite en C++ : la 3.0 sera réécrite en Rust avec pour objectif affiché de devenir /usr/bin/ld sur la plupart des distributions. Pour qui compile beaucoup, c’est la promesse de liens en quelques centaines de millisecondes au lieu de secondes ou de minutes.
11 septembre 2026. Rui Ueyama publie Mold 2.42.1, la version la plus rapide de l’éditeur de liens qu’il a créé en 2020 — et, si tout se passe comme prévu, la dernière écrite en C++. Les notes de version annoncent deux décisions lourdes : une réécriture complète en Rust livrée sous le nom de Mold 3.0, et un objectif explicite — faire de mold le /usr/bin/ld par défaut des distributions Linux. Ce n’est pas un simple changement de langage. C’est un pari sur deux décennies d’avenir de la chaîne de compilation.
La dernière version C++ d’un outil vieux de six ans
Mold s’est imposé depuis 2020 comme le linker le plus rapide du marché, devant LLVM lld et le récent wild, lui aussi écrit en Rust. Les notes de la 2.42.1 le revendiquent en toutes lettres : mold « est aussi rapide, voire plus rapide » que ses concurrents. La version apporte au passage des correctifs sur les builds LTO, le débogage et la gestion des exceptions C++.
Mais l’essentiel n’est pas dans les correctifs. Il est dans la feuille de route. Rui Ueyama écrit que « 2.42.1 est probablement la dernière version C++ du linker, sauf s’il nous faut publier un autre correctif ». La version Rust sortira sous le numéro 3.0.
Le raisonnement tient en trois phrases. Un outil comme mold peut rester en service « des décennies ». À cette échelle, mold est encore jeune. Et le réécrire en Rust maintenant, quand le langage a mûri, est le bon moment — quand Ueyama a commencé en 2020, Rust était encore « relativement nouveau » ; en 2026, il offre des performances comparables au C++ avec, en plus, des garanties de sûreté mémoire.
Devenir le linker par défaut : le vrai objectif de la 3.x
La réécriture n’est que le moyen. La cible, c’est le /usr/bin/ld de votre distribution.
Le constat de Ueyama est sans appel : « au cours des vingt dernières années, plusieurs linkers rapides — gold, lld, mold — ont été développés. Pourtant, le linker système, /usr/bin/ld, sur la plupart des distributions Linux est toujours GNU ld. » Conséquence directe : « des travaux de liaison que mold termine en quelques centaines de millisecondes peuvent encore prendre plusieurs secondes, des dizaines de secondes, voire des minutes avec le linker par défaut. »
Il endosse sa part de responsabilité. Auteur original de lld et de mold, il reconnaît avoir passé « beaucoup d’efforts à rendre les linkers plus rapides, mais pas assez sur le travail de compatibilité nécessaire pour faire d’un linker rapide un remplaçant direct du linker système ». La série 3.x doit changer cela.
Le chemin technique est connu : implémenter les fonctionnalités de scripts de linker encore manquantes, pour que mold puisse lier non seulement des programmes utilisateur, mais aussi des noyaux et des firmwares. Suivront des tests de compatibilité extensifs et un travail rapproché avec les mainteneurs de distributions. C’est, écrit-il, « l’une de nos plus hautes priorités pour mold 3.x ».
Le détail n’est pas anodin. C’est précisément sur ces scripts de linker que ld.gold puis lld ont, historiquement, buté pour devenir le lien par défaut de certaines distributions — les noyaux et les firmwares dépendent d’idiomes de scripts que les linkers « modernes » ne couvraient pas.
Une réécriture assumée, pas une fuite en avant
Réécrire un programme établi comporte des risques, et Ueyama ne les minimise pas. « Les progrès récents du codage assisté par IA rendent les réécritures à grande échelle nettement plus pratiques, mais ils n’éliminent pas ces risques », écrit-il. La confiance est le capital de mold : « les gens font confiance à mold parce qu’il fonctionne, et nous ne pouvons pas nous permettre de perdre cette confiance. »
Le contrat passé avec l’utilisateur est clair : du point de vue de celui qui compile, mold 3.0 devra se comporter exactement comme les 2.x, seule l’implémentation changeant sous le capot.
Sur l’édition de liens incrémentale, le ton change aussi. Ueyama précise n’avoir jamais été contre, mais avoir d’abord voulu rendre le lien complet si rapide qu’il « s’approche de la vitesse d’une simple copie de fichier ». Si une approche simple de l’incrémental peut encore améliorer certains cas d’usage « significativement », l’équipe l’explorera — à condition de préserver « la simplicité et la fiabilité de mold ».
Ce que ça change pour vous
- Si vous compilez en C++ ou Rust à grande échelle (monorepos, builds CI longs), le passage à mold reste, dès aujourd’hui, le levier le plus rentable pour réduire le temps de liaison. La 2.42.1 est un choix sûr ; la réécriture ne change rien à son comportement.
- Si vous êtes mainteneur de distribution, la 3.x vous concerne directement : la promesse de Ueyama est un effort de compatibilité que
lldn’a jamais entièrement tenu sur les noyaux et firmwares. À suivre au moment des alphas. - Si vous gérez une chaîne de build verrouillée, gardez un œil sur le calendrier : 2.42.x restera la branche C++ de référence pendant toute la transition vers 3.0.
Le point de vigilance est ailleurs. Une réécriture pilotée en partie par IA sur un outil aussi central que le linker mérite d’être observée de près : les gains de productivité annoncés ne dispensent pas de la relecture humaine des chemins critiques — l’édition de liens n’est pas un composant où un défaut subtil reste sans conséquence.
Verdict
Mold 2.42.1 est une version de continuité : adoptez-la si vous êtes déjà sur mold, testez-la si vous cherchez à accélérer vos builds sans rien changer d’autre.
La décision qui compte est celle de la 3.0. Si vous compilez des noyaux, des firmwares ou du code système et que vous rêvez d’un ld plus rapide, suivez les versions alpha de mold 3.x : c’est là que se jouera la compatibilité qui fera — ou non — de mold le linker par défaut de Linux. Si vous êtes simplement pressé par vos temps de CI, n’attendez pas la réécriture : la 2.42.1 livre déjà le gain, aujourd’hui, sans le risque.