Makefile dépendance de lien automatique?

Question

Il est facile de laisser le programme déterminer la dépendance au moment de la compilation (avec gcc -MM). Néanmoins, la dépendance au lien (décider à quelles bibliothèques devraient être liées) semble difficile à déterminer. Ce problème est devenu émergent lorsque plusieurs cibles avec des bibliothèques individuelles à lier sont nécessaires.

Par exemple, trois cibles de bibliothèques dynamiques t1.so, t2.so et t3.so doivent être créées. t1.so a besoin d'une bibliothèque mathématique (-lm), contrairement à t2 et t3. Il serait fastidieux d'écrire des règles distinctes. Une seule règle nécessitant les trois cibles liées à la bibliothèque mathématique permet d'éviter les problèmes. Cependant, cela provoque un gonflement de la taille cible car la bibliothèque mathématique n'est pas utilisée pour t2.so et t3.so.

Des idées?

Answer 1

Ce n'est pas aussi facile à trouver que de trouver les en-têtes nécessaires. gcc -MM est juste une façon élégante d'utiliser le préprocesseur, mais il ne sait pratiquement rien de la façon dont le code est utilisé ou fonctionne: vous pouvez inclure certains en-têtes pleins de #define ou introduire des dépendances de bibliothèques de dépendances complexes. Je voudrais coller à l'écriture des dépendances de liaison explicites pour toutes les cibles (3 dans votre cas). Vous pouvez collecter des dépendances communes dans LDFLAGS.

Answer 2

Il semble que l'option ld--trace est un bon début. La sortie a besoin de formatage, mais je pense qu'il contient toutes les bonnes informations.

Mon appel ressemble à ceci:

$ g++ -o foo a.o b.o -l sfml-graphics -l sfml-window -Wl,--trace 
/usr/bin/ld: mode elf_i386 
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crt1.o 
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crti.o 
/usr/lib/gcc/i686-linux-gnu/4.6/crtbegin.o 
a.o 
b.o 
-lsfml-graphics (/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib/libsfml-graphics.so) 
-lsfml-window (/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib/libsfml-window.so) 
-lstdc++ (/usr/lib/gcc/i686-linux-gnu/4.6/libstdc++.so) 
-lm (/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/libm.so) 
-lgcc_s (/usr/lib/gcc/i686-linux-gnu/4.6/libgcc_s.so) 
/lib/i386-linux-gnu/libc.so.6 
(/usr/lib/i386-linux-gnu/libc_nonshared.a)elf-init.oS 
/lib/i386-linux-gnu/ld-linux.so.2 
-lgcc_s (/usr/lib/gcc/i686-linux-gnu/4.6/libgcc_s.so) 
/usr/lib/gcc/i686-linux-gnu/4.6/crtend.o 
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crtn.o 

Answer 3

Avez-vous essayé d'utiliser 'nm'? Il vous donne une liste des définis et des symboles non définis dans l'objet/fichiers de bibliothèque (voir la documentation here

Il y a une approche mentionnée dans cette post par Bernd Strieder que j'envisage d'utiliser -.

1. Use nm to generate a list of symbols in all object/library files involved. 
2. This file is parsed and basically the (U)ndefined and (T)ext symbols 
    and the symbols of main functions are filtered out and mapped to their 
    object files. I found that U and T symbols suffice, which reduces the 
    overall problem considerably compared to the linker, which has to 
    consider all symbols. 
3. The transitive hull of the dependency relation according to U and T 
    symbols between object files is being calculated. 
4. A list of object files needed to resolve all dependencies can be 
    printed for any object file. 
5. For any main object file, a make target to link it is arranged.