Wild, l'éditeur de liens écrit en Rust bâti autour de l'idée que la plupart des éditions de liens sont des ré-éditions, a publié sa version 0.10 le 4 août. La fonctionnalité phare est --gdb-index, qui précalcule l'index de symboles que GDB construirait sinon au démarrage et l'intègre au binaire. L'entrée la plus surprenante est un changement de valeur par défaut : sur btrfs et vfat, Wild cesse de projeter son fichier de sortie en mémoire, parce que le faire ralentissait l'édition de liens. Le reste tient surtout à des scripts d'édition de liens et à des corrections, exactement ce qu'un linker à ce stade de sa vie devrait livrer.
The short answer
Wild est un éditeur de liens Linux rapide écrit en Rust et pensé pour le développement itératif. La version 0.10 ajoute --gdb-index, qui précalcule la section .gdb_index pour que le débogueur ne la reconstruise pas à chaque démarrage, avec traitement parallèle des symboles et écriture concurrente. Sur btrfs et vfat, Wild ne projette plus le fichier de sortie en mémoire par défaut, ce que les notes de version présentent comme un gain de vitesse. Le reste est un gros lot de fonctionnalités de scripts, un début de 32 bits, du WebAssembly, du Mach-O et libwild en mémoire.
L'éditeur de liens est la partie de la compilation à laquelle personne ne pense, jusqu'au jour où on ne pense plus qu'à elle. Wild existe pour ce moment-là : c'est un linker Linux écrit en Rust dont le but affiché est d'être très rapide sur ce que vous faites réellement cent fois par jour, c'est-à-dire non pas lier un projet depuis zéro, mais le relier après avoir modifié un seul fichier.
La version 0.10 est arrivée le 4 août. Les notes de version posent les attentes honnêtement : cette sortie apporte beaucoup de corrections de bugs, et la plupart des nouveautés concernent les scripts d'édition de liens. C'est le discours d'un projet qui mûrit, et deux entrées méritent d'en être extraites.
gdb-index, enfin
L'option s'appelle --gdb-index, et elle fait ce que son équivalent fait dans GNU gold, LLD et Mold : elle construit la section .gdb_index au moment de l'édition de liens et l'intègre au binaire.
L'intérêt devient évident dès qu'on voit où se situe le coût. Les informations de débogage sont dispersées dans toutes les unités de compilation du binaire. Quand GDB démarre sans index, il doit les parcourir pour se faire une idée de l'endroit où les symboles sont définis avant de pouvoir répondre utilement à quoi que ce soit. Sur un gros binaire, c'est une pause perceptible à chaque session. L'éditeur de liens a déjà tout lu et sait où chaque élément a atterri : il peut donc écrire la réponse une fois plutôt que de laisser le débogueur la recalculer indéfiniment.
L'implémentation de Wild mérite une mention. La fonctionnalité était demandée depuis 2025, et la version la décrit comme parallélisée, avec un traitement des symboles réparti sur plusieurs fils et un index écrit de façon concurrente, ainsi qu'une allocation sur le tas réduite. Cela compte pour un linker dont tout l'argument est la vitesse. Ajouter un index qui aurait ralenti chaque édition de liens aurait été un mauvais échange.
La découverte sur btrfs
L'autre entrée est le genre de détail qu'on ne trouve qu'en profilant sur de vraies machines : Wild évite désormais de projeter le fichier de sortie en mémoire quand ce fichier se trouve sur btrfs ou vfat, et cela accélère l'édition de liens.
La technique par défaut d'un linker consiste à projeter la sortie en mémoire et à écrire le binaire fini à travers cette projection, en laissant l'écriture différée au noyau. Sur ext4 ou xfs, c'est un chemin efficace. Sur btrfs, système en copie sur écriture, salir des pages projetées entraîne le système de fichiers dans une comptabilité qu'une écriture séquentielle simple éviterait, et l'addition tombe sur votre temps de compilation. vfat est lent ici pour des raisons plus anciennes et plus simples.
Wild 0.10 détecte les deux cas et bascule automatiquement sur --no-mmap-output-file. Le conseil du projet, énoncé dans la version, va plus loin que le contournement : quand vous avez le choix, ne placez pas la sortie de compilation sur l'un de ces systèmes de fichiers. C'est un bon conseil quel que soit votre linker, et la plupart des gens qui utilisent btrfs en racine ne se sont jamais demandé sur quel sous-volume vivait leur répertoire target/.
La majorité ingrate
Tout le reste de cette version relève du travail de compatibilité, et c'est ce qui rend le projet utilisable tout court.
Les ajouts de scripts d'édition de liens forment le gros du lot : DISCARD pour jeter des sections, les directives SORT pour l'ordre des sections, la commande DEFINED pour tester l'existence d'un symbole, les expressions ternaires dans l'arithmétique d'adresses. Rien de tout cela n'est passionnant à lire. Tout cela fait la différence entre un linker que vous pouvez pointer sur un projet embarqué ou proche du noyau et un linker que vous ne pouvez pas y pointer, parce que ces projets traînent des scripts écrits il y a des années pour GNU ld et ne les réécriront pas pour vous.
Au-delà : un début de support 32 bits, l'édition de liens de programmes WebAssembly élargie, la poursuite du travail Mach-O, et la gestion de fichiers en mémoire dans libwild pour que les outils de compilation puissent appeler Wild comme bibliothèque en lui passant des entrées qui ne touchent jamais le disque. Les mesures de la version montrent des performances globalement alignées sur la 0.9, ce qui est le bon résultat pour une sortie qui ajoute un écrivain d'index.
Ce que nous ferions
Essayer, mesurer, garder le retour arrière sous la main.
Changer de linker est l'une des expériences les moins coûteuses à la portée d'un développeur : une option dans votre configuration de compilation, et une option pour l'annuler. Si votre projet met du temps à l'édition de liens et que vous passez la journée dans la boucle éditer, compiler, déboguer, Wild vous vise directement, et la 0.10 lève l'une des objections récurrentes en gérant l'index du débogueur.
La seule chose que nous vérifierions d'abord n'a rien à voir avec Wild : sachez sur quel système de fichiers se trouve votre répertoire de compilation. Si la réponse est btrfs, vous le payez à chaque édition de liens, quel que soit le linker, et cela mérite d'être su que vous basculiez ou non.
Sources et pour aller plus loin
- Notes de version de Wild 0.10.0 sur GitHub
- Wild Linker 0.10 released with GDB index support, mitigation for btrfs performance, Phoronix, 4 août 2026
- Le dépôt du projet Wild
- Documentation GDB sur les fichiers d'index et la section .gdb_index
Questions fréquentes
Que me fait gagner concrètement --gdb-index ?
Le temps de démarrage du débogueur, et sur un gros binaire ce n'est pas anecdotique. Sans index, GDB doit parcourir les informations de débogage de chaque unité de compilation du binaire avant de pouvoir répondre à une question sur un symbole, et vous payez ce coût à chaque ouverture de session. La section .gdb_index est une carte précalculée des noms vers les endroits qui les définissent, ce qui permet au débogueur d'aller droit au but. L'éditeur de liens est le bon endroit pour la construire parce qu'il est le seul à avoir déjà lu toutes les informations de débogage et à savoir où chaque chose a atterri. GNU gold a introduit l'idée, LLD et Mold la portent tous les deux, et son arrivée dans Wild supprime l'une des dernières raisons pour un projet très orienté débogage de ne pas basculer.
Pourquoi la projection mémoire du fichier de sortie serait-elle plus lente sur btrfs ?
Parce que les systèmes de fichiers en copie sur écriture et une sortie basée sur mmap font mauvais ménage. L'astuce habituelle d'un linker consiste à projeter le fichier de sortie en mémoire et à écrire le binaire fini à travers cette projection, en laissant le noyau gérer l'écriture différée. Cela fonctionne bien sur ext4 et xfs. Sur un système en copie sur écriture comme btrfs, salir des pages via une projection force le système de fichiers à un travail qu'une simple écriture séquentielle éviterait, et la comptabilité associée se voit sur le temps écoulé. vfat a ses propres raisons, principalement qu'il n'a jamais été conçu pour ce motif d'accès. Wild 0.10 détecte les deux cas et bascule par défaut sur --no-mmap-output-file, ce que les notes de version décrivent comme un léger gain de vitesse. La recommandation du projet va plus loin : si vous le pouvez, ne placez pas votre répertoire de compilation sur l'un de ces deux systèmes.
Wild peut-il remplacer mon éditeur de liens actuel ?
Cela dépend de l'axe qui vous intéresse. Pour le développement itératif sous Linux x86 64, le cas pour lequel Wild a été conçu, il est crédible aujourd'hui et des gens l'utilisent déjà ainsi. Pour tout le reste, considérez-le comme prometteur plutôt qu'abouti : le support 32 bits est décrit comme un début dans cette version, Mach-O est en cours, et l'édition de liens WebAssembly progresse sans être complète. Le résumé honnête, c'est que Wild est un linker Linux rapide avec une ambition précise, l'édition de liens incrémentale, qu'il n'a pas encore pleinement tenue. Notre conseil vaut pour tout changement de linker : c'est une ligne à changer pour essayer et une ligne pour revenir en arrière, alors mesurez sur votre propre compilation plutôt que sur le banc d'essai d'un autre.
À quoi servent tous ces changements de scripts d'édition de liens ?
À la compatibilité, la moitié ingrate de l'écriture d'un linker. Tout ce qui prétend remplacer GNU ld doit composer avec les scripts d'édition de liens qui existent déjà, et ces scripts utilisent une longue traîne de fonctionnalités : DISCARD pour jeter des sections, les directives SORT pour contrôler l'ordre des sections, DEFINED pour tester l'existence d'un symbole, des expressions ternaires dans l'arithmétique d'adresses. Les projets embarqués et les noyaux s'appuient beaucoup dessus. Chaque fonctionnalité implémentée par Wild, c'est un projet de plus qui peut l'essayer sans réécrire sa compilation. Les notes de version disent clairement que la plupart des nouveautés de ce cycle concernent les scripts, ce qui indique où se trouvaient les frottements restants.
Qu'est-ce que libwild et pourquoi les fichiers en mémoire comptent-ils ?
libwild, c'est Wild exposé comme bibliothèque plutôt que comme binaire en ligne de commande, afin qu'un outil de compilation puisse éditer les liens en l'appelant au lieu de lancer un processus. La gestion des fichiers en mémoire signifie que l'appelant peut lui fournir des entrées qui n'ont jamais touché le disque. Cette combinaison vise directement les systèmes de compilation et les chaînes d'outils qui génèrent du code objet et veulent immédiatement l'éditer : supprimer l'écriture d'un fichier temporaire, le lancement de processus et la relecture retire une vraie surcharge sur les compilations qui lient beaucoup de petits artefacts. C'est de l'infrastructure pour les outils des autres plutôt qu'une fonctionnalité que vous utilisez directement, et c'est un bon indice de l'endroit où le projet s'attend à être intégré.