dll linking static library - unresolved linker symbols from unused functions

Question

I have a static library staticLibA.lib that provides a number of functions. some of them require some external functions that are not provided within this library.

Additionally i define a dynamic library dynLib.dll that uses some of the static libraries functions, but none of the functions that require the mentioned external functions.

But if i link the dynamic library I get unresolved external symbols despite the fact that they should not be necessary.

Should not the compiler only select the functions from the static lib that the target does require?

here a little example

staticLib.lib:

// staticLib_fileA.c

extern void extLibFunction();
void slib_funcA(){
  extLibFunction();
  // some stuff
}

// staticLib_fileB.c

void slib_funcB(){
  // some stuff
}

dynLib.dll

// dynLib.c

void dyn_func(){
  slib_funcB();
  // some stuff
}

the compilation/link of dynLib.dll brings the unsolved symbol extLibFunction :

staticLib.lib(staticLib_fileA.obj) : error LNK2001: unresolved external symbol extLibFunction

Is there some way around this? some compiler settings that told to just link the actual required symbols. A work around is some dummy implementation, but I would prefer some way that only forces the user of the lib to do something if he needs these parts

Answer 1

Unlike static libraries, DLLs can not have unresolved symbols(references). A DLL allows a binary to access all of the symbols at runtime, even some of them were not needed. A library is made from .o files. Some of these .o files from a library might contain symbols that are not used in your program. At link time, your static library can have unresolved symbols as long as you do not need these unresolved symbols or any other symbol from a .o file which contains unresolved symbols. With DLL, the thing is not the same and you must resolve all references at link time, even if your program doesn't need them.

Answer 2

It seems that the object files at a whole have dependencies at each other because of other functions within fileB.obj that leads to dependency of fileA.obj .

And because of this, also the external dependency has to be fullfilled, even if the function that uses this dependency never gets called (or in case of dll: gets exported) in the linked binary and not even gets called in fileB .

This seems to be even true if "function level linking" and "Comdat Folding" is enabled.

Why this is true is explained by Raymond Chen in a series of blog articles around the principle of linking:

https://devblogs.microsoft.com/oldnewthing/tag/linker

As it turns out, even with advanced techniques (like the above mentioned) the first step is the classical approach that has to get all its symbols resolved, even if the optimizing afterwards will strip these symbols again.