Geek Answers Handbook

Automatic link dependency Makefile?

It is easy to let the program determine the dependency at compile time (using gcc -MM). However, link dependency (the decision about which libraries should be linked) seems difficult to understand. This problem occurs when multiple targets with separate libraries for reference are needed.

For example, you need to create three dynamic library objects t1.so, t2.so, and t3.so. t1.so needs a math library (-lm), but t2 and t3 do not. It would be tiring to write separate rules. The only rule requiring three goals related to the math library eliminates this problem. However, it causes inflation of the target size since the math library is not used for t2.so and t3.so.

Any ideas?

+5
source share
3 answers

It's not easy to figure out how to find the right headings. gcc -MM- this is just some kind of fancy way of using the preprocessor, but it knows almost nothing about how the code is used or works: you can include some full headers #defineor add dependency dependency library dependencies.

I would stick with writing explicit binding links for all purposes (3 in your case). You can collect common dependencies in LDFLAGS.

+1
source

The option seems to be a ld --tracegood start. The output requires formatting, but I think it contains all the necessary information.

:

$ 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
+1

Have you tried using "nm"? It gives you a list of defined and undefined characters in object / library files (see the documentation here .

It mentions the approach mentioned in this post from Bernd Strieder, which I am considering with -

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.
0
source

More articles:


All Articles