Dependencia de enlace automático de archivo Makefile?

Question

Es fácil dejar que el programa averigüe la dependencia en tiempo de compilación, (con gcc -MM). Sin embargo, la dependencia del enlace (decidir a qué bibliotecas se debe vincular) parece ser difícil de descubrir. Este problema se vuelve emergente cuando se necesitan objetivos múltiples con bibliotecas individuales para vincular.

Por ejemplo, se deben crear tres destinos dinámicos de biblioteca t1.so, t2.so y t3.so. t1.so necesita una biblioteca matemática (-lm), mientras que t2 y t3 no. Sería tedioso escribir reglas separadas. Una sola regla que requiera los tres objetivos vinculados con la biblioteca matemática salva el problema. Sin embargo, causa una inflación del tamaño objetivo, ya que la biblioteca matemática no se usa para t2.so y t3.so.

¿Alguna idea?

Answer 1

Esto no es tan fácil de encontrar como encontrar los encabezados necesarios. gcc -MM es solo una forma elegante de usar el preprocesador, pero no sabe casi nada sobre la forma en que se usa o funciona el código: puede incluir algunos encabezados llenos de #define o introducir dependencias de biblioteca de dependencias complejas.

Me quedaría con escribir dependencias de enlace explícitas para todos los objetivos (3 en su caso). Puede recopilar dependencias comunes en LDFLAGS.

Answer 2

Parece que la opción ld de --trace es un buen comienzo. La salida necesita formato, pero creo que contiene toda la información correcta.

Mi invocación es como la siguiente:

$ 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

¿Ha intentado utilizar 'nm'? Se le da una lista de símbolos definidos e indefinidos en los ficheros objeto/biblioteca (consulte la documentación here

Hay un enfoque mencionado en este post por Bernd Strieder que estoy pensando en utilizar -.

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.