Le gold l'éditeur de liens a été conçu comme un éditeur de liens spécifique à ELF, avec l'intention de produire un éditeur de liens plus maintenable et plus rapide que BFD ld (l'éditeur de liens "traditionnel" GNU binutils). Effet secondaire, il est en effet capable de lier de très gros programmes utilisant moins de mémoire que BFD ld , probablement parce qu'il y a moins de couches d'abstraction à gérer et parce que les structures de données de l'éditeur de liens correspondent plus directement au format ELF.
Je ne suis pas sûr qu'il existe beaucoup de documentation traitant spécifiquement des différences de conception entre les deux éditeurs de liens et de leur effet sur l'utilisation de la mémoire. Il existe une série d'articles très intéressants sur les éditeurs de liens par Ian Lance Taylor, l'auteur des différents éditeurs de liens GNU, qui explique de nombreuses décisions de conception menant à gold . Il écrit que
Le linker sur lequel je travaille actuellement, appelé gold, sera mon troisième. C'est exclusivement un lieur ELF. Encore une fois, l'objectif est la vitesse, en l'occurrence être plus rapide que mon second linker. Cet éditeur de liens a été considérablement ralenti au fil des ans en ajoutant la prise en charge d'ELF et des bibliothèques partagées. Cette prise en charge a été corrigée plutôt que conçue.
(Le deuxième lieur est BFD ld .)
L'éditeur de liens Gold a été écrit pour accélérer considérablement le processus de création de liens. Selon l'auteur d'or Ian Lance Taylor
Pour le moment, l'or n'a qu'un seul avantage significatif par rapport au lieur existant :il est plus rapide. Sur de gros programmes C++, j'ai mesuré qu'il s'exécutait cinq fois plus vite.
Il compare les performances du linker or avec le linker GNU traditionnel. gold (contrairement à l'éditeur de liens GNU) n'utilise pas la bibliothèque BFD pour traiter les fichiers objets.
La limitation de gold est que (contrairement à l'éditeur de liens GNU qui peut traiter de nombreux types de fichiers objets), il ne peut lier que des fichiers objets au format ELF.
Concernant les problèmes que vous avez rencontrés lors de l'utilisation de l'éditeur de liens GNU, voici une réponse intéressante à une question similaire sur SO de Michael Adam :
Le gold linker a même trouvé quelques problèmes de dépendances dans notre code, puisqu'il semble être plus correct que le classique par rapport à certains détails. Voir, par ex. ce commit Samba.
gold contre ld référence
J'ai publié un benchmark synthétique concret de ld vs gold sur :https://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263
Résumé des résultats :l'or était 2x à 3x plus rapide que ld.
Ce gain de temps peut changer considérablement la donne sur des projets C++ complexes avec des modèles et une génération de code incontrôlables, car l'étape de liaison implique tous les fichiers du projet, et contrairement à la compilation, elle doit toujours être effectuée, même si vous modifiez un seul fichier .cpp.
Ainsi, un temps de liaison lent rend le cycle de développement insupportable et est probablement la principale raison pour laquelle Google y a investi des ressources. Imaginez simplement les avantages d'attendre 10 s au lieu de 30 s pour chaque changement de fichier trivial.
Les gains de temps du benchmark synthétique concordaient également avec les gains réels que j'avais sur un projet complexe du monde réel (gem5), comme également mentionné dans cette réponse.