Why does the C++ linker require the library files during a build, even though I am dynamically linking?

Question

I have a C++ executable and I'm dynamically linking against several libraries (Boost, Xerces-c and custom libs).

I understand why I would require the .lib/.a files if I choose to statically link against these libraries ( relevant SO question here ). However, why do I need to provide the corresponding .lib/.so library files when linking my executable if I'm dynamically linking against these external libraries?

Answer 1

The compiler isn't aware of dynamic linking, it just knows that a function exists via its prototype. The linker needs the lib files to resolve the symbol. The lib for a DLL contains additional information like what DLL the functions live in and how they are exported (by name, by ordinal, etc.) The lib files for DLL's contain much less information than lib files that contain the full object code - libcmmt.lib on my system is 19.2 MB, but msvcrt.lib is "only" 2.6 MB.

Note that this compile/link model is nearly 40 years old at this point, and predates dynamic linking on most platforms. If it were designed today, dynamic linking would be a first class citizen (for instance, in .NET, each assembly has rich metadata describing exactly what it exports, so you don't need separate headers and libs.)

Answer 2

Raymond Chen wrote a couple blog entries about this specific to Windows. Start with The classical model for linking and then follow-up withWhy do we have import libraries anyway? .

To summarize, history has defined the compiler as the component that knows about detailed type information, whereas the linker only knows about symbol names. So the linker ends up creating the .DLL without type information, and therefore programs that want to link with it need some sort of metadata to tell it about how the functions are exported and what parameter types they take and return.

The reason .DLLs don't have all the information you need to link with them directly is is historic, and not a technical limitation.

Answer 3

For one thing, the linker inserts the versions of the libraries that exist at link time so that you have some chance of your program working if library versions are updated. Multiple versions of shared libraries can exist on a system.

Answer 4

The linker has the job of validating that all your undefined symbols are accounted for, either with static content or dynamic content.

By default, then, it insists on all your symbols being present.

However, that's just the default. See -z, and --allow-shlib-undefined, and friends.

Answer 5

Perhaps this dynamic linking is done via import libraries (function has __declspec(dllimport) before definition).
If this is the way than compilator expects that there's __imp_symbol function declared and this function is responsible for forwarding call to the right library dynamically loaded.
Those functions are generated during linkage of symbols with __declspec(dllimport) keyword

Answer 6

Here is a very SIMPLIFIED description that may help. Static linking puts all of the code needed to run your program into the executable so everything is found. Dynamic linking means some of the required code does not get put into the executable and will be found at runtime. Where do I find it? Is function x() there? How do I make a call to function x()? That is what the library tells the linker when you are dynamically linking.