Je suis en train de compiler une grosse application sous redhat 9. Sous la redhat 7.3, avec un gcc 3.0, le link me prenais environs 5 minutes.
 
Maintenant, je que suis passé sous la 9 avec gcc 3.2.2, le link de la même application me prends près d'une heure. M'emmerdant un maximum, j'ai accroché un gdb à ld et fait un backtrace pour avoir la pile d'appel histoire de savoir ce qu'il fait.
 
Il passe son temps dans la fonction _bfd_merge_section. J'ai fait quelques recherches, je suis tombé là dessus :  
 
http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg01403.html
 
Mais si je lance le link avec l'option -fno-merge-constants, j'ai pas de différences de vitesse. Si je rattache mon gdb, j'obtient le même résultat de backtrace. A noter que je ne semble pas passer du temps sur htab_find_slot_with_hash, contrairement au cas exposé plus haut.
 
Voyez vous d'ou peux venir cette différence de vitesse de link ?

Un détail complémentaire, le CPU est scotché à 100% et ne passe pas de temps en mode noyau. Au début, je soupsonnait un DMA non activé sur le disque, mais cela ne semble pas être ça.

J'ai bidé

mais est ce que ça vaut pas le coup d'attendre ?

 
C'est un problème de vitesse du cycle de développement. Pour une compile tous les 36 du mois, c'est pas génant. Malheureusement, je suis en phase de debuggage intensif, et donc pour être productif, je vois avec une vitesse de link plus rapide. Je ne peux pas me permettre d'attendre une heure de pouvoir tester ma modification.

Je up, parceque je me pose la même question