What is the usefulness of a .lib file generated when compiling dll projects, can I use it for static binding?

Question

I want to ask the utility of the .lib file that is created when the dll project is compiled.

When compiling our projects, the following files are generated: .dll .exp .lib .pdb

Now that we also have a .lib file, we can use this file to statically link it to any other project. If not, then why generate a .lib file.

Answer 1

.lib created with the .dll is called the "import library" and it allows you to use the dll functions, including their header, as if they were statically linked in your executable file. It ensures that when the linker needs to fix the dll function addresses that reference the object files, it can find them inside the import library. Such functions found in the import library are actually stubs that extract the actual address of the corresponding function in the loaded dll from the import address table and jump directly to it (traditionally, now there is some ingenuity in the linker that avoids this double Jump).

The import library, in turn, contains special instructions for the linker, which instruct it to generate the corresponding entries in the import table of the executable file, which, in turn, is read at boot by the loader ("dynamic linker", in Unix terms). This ensures that the referenced DLLs are loaded before the entry point of your executable is called, and the IAT contains the correct addresses of the referenced functions.

Note that all this is basically just a convenience, allowing you to call the dll functions as if they were statically linked to your executable. You do not need a .lib file if you explicitly handle the dynamic load / function search (using LoadLibrary and GetProcAddress); it’s just more convenient to delegate all these things to the linker and the loader.

Answer 2

.lib for the shared library is not used for static linking, it is used to give the linker an idea of ​​what is hidden inside. Dll file. Think of it as the header file that you pass to the linker to make sure that it knows about all the functions that belong to the DLL and what you need. Ask yourself: how to use this generated DLL file without .lib? LoadLibrary is not taken into account - it has difficulties (class methods? Mangling?) And creates uncertainty, for example, with opencv_ffmpeg.dll: it cannot exist in PATH, and the program associated with opencv_video will still work, but will not tell us anything , and also without playing the video without it - there is no explicit error message. In addition, this method is platform specific.

Static library on the other hand

.lib contains a fully functional object file that directly enters the executable file.

The main idea - whether it be a static or shared library, you should still link them almost the same way - but then, if it was a shared library, your program will NOT start without including the corresponding DLL in the distribution.