Makefile automatische Linkabhängigkeit?

Question

Es ist einfach, das Programm die Abhängigkeit zur Kompilierzeit herausfinden zu lassen (mit gcc -MM). Dennoch scheint es schwierig zu sein, die Linkabhängigkeit (die Entscheidung, mit welchen Bibliotheken verbunden werden soll) herauszufinden. Dieses Problem tritt auf, wenn mehrere Ziele mit einzelnen zu verknüpfenden Bibliotheken benötigt werden.

Zum Beispiel müssen drei dynamische Bibliotheksziele t1.so, t2.so und t3.so erstellt werden. t1.so benötigt eine Math-Bibliothek (-lm), während t2 und t3 nicht funktionieren. Es wäre mühsam, separate Regeln zu schreiben. Eine einzige Regel, die die drei mit der Mathematikbibliothek verknüpften Ziele erfordert, erspart das Problem. Es verursacht jedoch eine Inflation der Zielgröße, da die Mathematikbibliothek für t2.so und t3.so nicht verwendet wird.

Irgendwelche Ideen?

Answer 1

Dies ist nicht so einfach herauszufinden, wie benötigte Header zu finden. gcc -MM ist nur eine schicke Möglichkeit, den Präprozessor zu verwenden, aber es weiß ziemlich nichts über die Art und Weise, wie der Code verwendet wird oder funktioniert: Sie könnten einige Header mit #define oder komplexe Abhängigkeiten Bibliothek Abhängigkeiten einfügen.

Ich würde beim Schreiben explizite Verknüpfung Abhängigkeiten für alle Ziele bleiben (3 in Ihrem Fall). Sie können allgemeine Abhängigkeiten in LDFLAGS sammeln.

Answer 2

Es sieht aus wie ld 's --trace Option ist ein guter Anfang. Die Ausgabe benötigt Formatierung, aber ich denke, sie enthält alle richtigen Informationen.

Mein Aufruf sieht wie folgt aus etwas:

$ 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

Haben Sie versucht, 'nm' verwenden? Es gibt Ihnen eine Liste der definierten und undefinierten Symbole in Objekt-/Bibliotheksdateien (siehe Dokumentation here

Es ist ein Ansatz in diesem post von Bernd Strieder erwähnt, dass ich angesichts bin mit -.

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.