2
votes

Assume a static library libfoo that depends on another static library libbar for some functionality. These and my application are written in D. If my application only uses libfoo directly, and only calls functions from libfoo that do not reference symbols from libbar, sometimes the program links successfully without passing libbar to the linker and other times it doesn't.

Which of these happens seems to depend on what compiler I'm using to compile libfoo, libbar and my application, even though all compilers use the GCC toolchain to link. If I'm using DMD, I never receive linker errors if I don't pass libbar to the linker. If I'm using GDC, I sometimes do, for reasons I don't understand. If I'm using LDC, I always do.

What determines whether the GCC linker fails when a symbol referred in libfoo is undefined, but this symbol occurs in a function not referred to by the application object file?

2

2 Answers

1
votes

What determines whether the GCC linker fails when a symbol referred in libfoo is undefined, but this symbol occurs in a function not referred to by the application object file?

If the linker complains about an unresolved symbol, then that is symbol is referenced from somewhere.

Usually the linker will tell you which object the unresolved reference comes from, but if it doesn't, the -Wl,-y,unres_symbol should.

You may also want to read this description of how the whole thing works.

1
votes

if the linker does no effort to eliminate dead (unused) code in the libraries it simply assumes all referenced symbols are used and tries to link them in

if it does the elimination (through for example a simple mark and sweep algo (note that you cannot fully decide if some code is unused as that problem can be reduced to the halting problem)) it can eliminate the unused libraries if they are never used

this behavior is implementation defined (and there may be linker flags you can set to en/disable it