Зависимость автоматической ссылки Makefile?

Легко позволить программе определить зависимость во время компиляции (с помощью gcc -MM). Тем не менее, зависимость от ссылок (решение, с какими библиотеками следует связываться) кажется трудной для понимания. Эта проблема возникает, когда требуется несколько целей с отдельными библиотеками для связи.

Например, необходимо построить три цели динамической библиотеки t1.so, t2.so и t3.so. t1.so нужна математическая библиотека (-lm), а t2 и t3 — нет. Было бы утомительно писать отдельные правила. Единственное правило, требующее, чтобы три цели были связаны с математической библиотекой, избавляет от проблем. Однако это приводит к увеличению целевого размера, поскольку математическая библиотека не используется для t2.so и t3.so.

Есть идеи?


person Kuang Chen    schedule 19.03.2010    source источник


Ответы (3)


Это не так просто понять, как найти нужные заголовки. gcc -MM — это просто какой-то причудливый способ использования препроцессора, но он почти ничего не знает о том, как используется или работает код: вы можете включить несколько заголовков, полных #define, или ввести сложные зависимости библиотеки зависимостей.

Я бы придерживался написания явных зависимостей связывания для всех целей (3 в вашем случае). Вы можете собрать общие зависимости в LDFLAGS.

person Benjamin Bannier    schedule 19.03.2010

Похоже, вариант --trace ld — хорошее начало. Вывод нуждается в форматировании, но я думаю, что он содержит всю правильную информацию.

Мой вызов выглядит примерно так:

$ 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
person thejoshwolfe    schedule 07.08.2012

Вы пробовали использовать «nm»? Он дает вам список определенных и не определенных символов в файлах объектов/библиотек (см. документацию здесь .

В этом сообщении Бернда Стридера упоминается подход, который Я рассматриваю возможность использования -

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.
person thegreendroid    schedule 24.08.2012
comment
Ссылка на пост битая. - person rudolfbyker; 26.12.2016