Ordre de l'édition des liens avec GCC

J'ai un petit souci d'édition des liens.
J'ai un énorme logiciel que je viens d'améliorer un peu avec des autotools pour la compilation. Chaque dossier génère une bibliothèque dynamique, chaque dossier regroupe les bibliothèques des sous-dossiers et à la fin tout est lié dans un exécutable.
Le problème, c'est que l'édition des liens est bizarre. Par exemple, une des bibliothèques demande, lors de lédition finale, à accéder à des fonctions qui sont dans les dernières bibliothèques liées, et ça plante. J'ai aussi fait le contraire, mettre la bibliothèque demandée en premier, mais ça ne marche pas. La seule solution est de mettre la bibliothèque manquante dans le parent de la bibliothèque qui demande les fonctions, et c'est pas génial, génial...
Aussi, j'ai une bibliothèque liée à une autre et cette dernière est liée au programme, la première n'est pas vue par le système, sauf si je demande explicitement l'édition des liens avec elle - et j'ai vérifié qu'elle était bien présente dans l'édition intermédiaire !

Une réponse ? - pour la FAQ :aie: un jour ? -

Oufff j'ai pas tout compris mais bon....

Utilises-tu un makefile avec l'outil make ?

[edit] = (en meme temps c'est plutôt logique ce que je viens de dire :aie: )

Oui, mais c'est la commande d'édition des liens qui pèche.

Sans doute un problème d'inclusion/liaison croisée, j'ai déjà eu le problème avec des inclusions croisées mais jamais pendant l'édition des liens. Si c'est ce genre de problème, c'est qu'une lib demande une autre mais que justement celle-ci demande l'autre ... un bins de ce genre quoi ... à voir :aie: Enfin c'est une piste.

Ce n'est pas ça, par exemple l'une des bibliothèques demandées est la version d'ITK de Zlib, et elle est juste demandée par une bibliothèque utilisant ITK :|

J'ai ptet pas saisi ton problème (il est tard :P). Mais s'il s'agit de dépendances entre lib à l'étape de l'édition de liens, il y a un ordre à respecter.
En effet, si A a besoin de symboles qui sont dans B, qui a besoin de symboles qui sont dans C
Alors, l'ordre de linkage final doit être A B C.

En effet, en gros, le linker construit "au fur et a mesure" une liste des symboles manquants, qui sont par la suite assignés selon ce qu'il trouve dans les autres elements à linker. Le truc, c'est que si tu le fais dans le mauvais sens (du genre C B A), il va arriver sur B, voir qu'il manque des tokens, le noter dans un coin, et essayer de voir s'il peut les remplir après (avec A, par exemple). Bien evidemment, il ne trouvera rien et plantera lamentablement : le linker n'a pas " l'intelligence" de garder en mémoire que des symboles manquants peuvent avoir été "vus" avant...

Voilou :)

Marche pas, la bibliothèque itkzlib était après les autres, ça plantait toujours...