8

I want to ask the usefullness of .lib file which is generated while compiling a dll project.

When we compile our projects, following files get generated: .dll .exp .lib .pdb

Now as we also have .lib file, can we use this file to statically link it to any other project. If not, then what is the use of this .lib file getting generated.

Sweekritee Singh
  • 172
  • 1
  • 9
  • You'll probably find [this question](https://stackoverflow.com/questions/3573475/how-does-the-import-library-work-details) informative. – WhozCraig Feb 01 '17 at 07:25
  • Hi Gray, the question asked there has completely different title, anybody trying to find answer for the similar question i have asked will not go searching for how the import library works, you must not duplicate it, at least for the sake of other user finding similar problem – Sweekritee Singh Feb 01 '17 at 21:08

2 Answers2

16

The .lib generated along with a .dll is called "import library", and it allows you to use the dll functions including their header as if they were statically linked in your executable. It makes sure that, when the linker has to fix up the dll function addresses referenced into object files, it can find them inside the import library. Such functions found into the import library are actually stubs which retrieve the actual address of the corresponding function in the loaded dll from the Import Address Table and jump straight to it (traditionally; now there is some smartness in the linker that allows to avoid this double jump).

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

Notice that all of this is mostly just convenience stuff to allow you to call dll functions as if they were statically linked into your executable. You don't strictly need the .lib file if you handle the dynamic load/function address retrieval explicitly (using LoadLibrary and GetProcAddress); it's just more convenient to delegate all this stuff to the linker and the loader.

Matteo Italia
  • 123,740
  • 17
  • 206
  • 299
4

.lib for shared library isn't used for static linking, it is used to give linker an idea of what is hidden inside a .dll file. Think of it as of header file that you give to the linker to make sure that it knows about all functions that belong to the .dll and that you need. Ask yourself a question: how would you use that generated .dll file without .lib? LoadLibrary doesn't count - it has complications(class methods? mangling?) and creates an uncertainty like with opencv_ffmpeg.dll: it can not exist within the PATH, and opencv_video-linked program will still run, but won't tell us anything, as well as it won't play videos without it - there's no explicit error message. Also, this method is platform-specific.

.lib static library, on the other hand, contains a full-fledged object file, which is directly included into the executable.

Basic idea - whether it is static or shared library, you still should link them both pretty much the same way - but then, if it was shared library, your program will NOT run without including the corresponding .dll into the distribution.

Leontyev Georgiy
  • 1,295
  • 11
  • 24
  • 1
    Actually, LoadLibrary is the most flexible method - everything else is built in terms of it - when you link against an import library you are delegating the LoadLibrary/GetProcAddress to the leader, and asking the compiler to write indirect calls through the IAT instead of straight function calls, but the low level plumbing is the same. – Matteo Italia Feb 01 '17 at 07:09
  • @MatteoItalia - Well, agreed. On the other hand, assembler is way more flexible in terms of performance and potential. Still, here we are coding on C++. – Leontyev Georgiy Feb 01 '17 at 07:12
  • @MatteoItalia What I mean is that everything is built off something, but if there's surely a better way(as it does expose errors in compile-time in this case, and doesn't require the programmer to know full function names poisoned with mangling, in which you can do a typo and debug it for eternity), why use the harder one? – Leontyev Georgiy Feb 01 '17 at 07:16
  • I'm not saying that you should always use LoadLibrary explicitly - actually, generally you don't, using the import library is much more convenient for the reasons you stated; what I'm saying is that it's incorrect to say that `LoadLibrary` has more limitations, when in facts it's the opposite - it's import library linking that is tied to a particular use case (and solves it very well), LoadLibrary/GetProcAddress are more general tools. – Matteo Italia Feb 01 '17 at 07:22
  • @MatteoItalia Fixed the answer. This is what I meant actually - more of *complications*, not *limitations*, to be exact. – Leontyev Georgiy Feb 01 '17 at 07:29