What is inside of a .lib file of Static library, Statically linked dynamic library and dynamically linked dynamic library?
How come there is no need for a .lib file in dynamically linked dynamic library and also that in static linking, the .lib file is nothing but a .obj file with all the methods. Is that correct?
In a static library, the lib file contains the actual object code for the functions provided by the library. In the shared version (what you referred to as statically linked dynamic library), there is just enough code to establish the dynamic linkage at runtime.
I'm not sure about "dynamically linked dynamic libraries" (loaded programmatically). Do you even link with a .lib in that case?Edit:
A bit late in coming, but no, you don't link a .lib. Well, you link to the lib with libraryloaderex in it. But for the actual library you're using, you provide your own bindings via C function pointers and loadlibrary fills those in.
Here's a summary:
In dll's are "things" like in an exe (there can be any kind of data, imports, exports, read/write/executable sections) but the difference is that an exe file exports only the entry point (function) but dll's export one/many functions.
For a static library, the .lib file contains all the code and data for the library. The linker then identifies the bits it needs and puts them in the final executable.
For a dynamic library, the .lib file contains a list of the exported functions and data elements from the library, and information about which DLL they came from. When the linker builds the final executable then if any of the functions or data elements from the library are used then the linker adds a reference to the DLL (causing it to be automatically loaded by Windows), and adds entries to the executable's import table so that a call to the function is redirected into that DLL.
You don't need a .lib file to use a dynamic library, but without one you cannot treat functions from the DLL as normal functions in your code. Instead you must manually call
LoadLibrary
to load the DLL (andFreeLibrary
when you're done), andGetProcAddress
to obtain the address of the function or data item in the DLL. You must then cast the returned address to an appropriate pointer-to-function in order to use it.I found following answer from Hans also useful here.It clears the air that there could two types of lib files.
A lib files is read by the linker and a dll file is used during execution. A lib file is essentially useless during execution and a linker is incapable of reading a dll file (except possibly in a manner irrelevant here).
The differences between the use of lib files for static and dynamic linking might be confusing but if you understand a little history then it becomes very clear.
Originally there were only static libraries. For a static library, the .lib file contains obj files. Each obj file is the output of one and only one compiler source code input file. A lib file is just a collection of related obj files, much like putting obj files in a directory. That is essentially what a lib file is, a library of obj files. For a static link, all of the obj files that an executable uses are combined into one file. Compare that to a dynamic link in which the executable is in a file separate from the other code it uses.
To implement dynamic linking, Microsoft modified the use of lib files such that they refer to a dll file instead of locations in an obj file. Other than that, all the information that is in a library for a static link is the same as for a dynamic link. They are all the same as far as the information in them except that a lib file for a dynamic link specifies the dll file.