Why does visual studio create a .LIB along with the .DLL?

Question

I have a project "Logger" wherein the configuration type is .dll.

"Logger" uses "libconfig" (an open source config parser). Currently, I have a separate project for "libconfig" and its configuration type is .lib

I added "libconfig" to Logger's frameworks and references setting with:

• link library depedencies = true
• use library dependency inputs = false

In Logger's linker command line, i see: /IMPLIB: "path\to\Logger.lib"

My question is: Why does Logger.lib need to be created? I see /OUT = "path\to\Logger.dll", but I'm trying to get a hang of visual studio's build process.

From M$'s IMPLIB doc, I see its part of the LINK process. I still don't get it.

Edit: I didn't mention how the Logger DLL was to be used. My application would be loading it at run-time (since this functionality is only required for specific cmd line args)

Penoyer

Answer 1

The DLL contains the code. The .lib file contains basically stubs for the functions in the file, that make it easy (and relatively fast) for the linker to put the correct information into an executable to use functions in the DLL.

Ultimately, there's no reason they'd have to do this -- it mostly keeps the linker a little simpler and faster, because it doesn't need (at least as much) special case code to deal with static vs. dynamic libraries. They could get around that by putting both the code and the linking information into a single file, but that would increase the file size (a little).

It probably doesn't mean much now, but back when Windows was new, quite a few programs were still distributed on 360K floppy disks, so minimizing the size of file you distributed to users was considered fairly important.

Mclemore

I see. So, while creating the executable, the .lib is linked along with everything else, but this .lib is really just a set of functions that hook 1:1 to the DLL's exported functions. Would that be right? – Penoyer

@Raja: They aren't really even functions -- just information to fill into the import table of the executable to tell the loader where to find the functions. – Mclemore

Wouldn't that depend on load-time v/s run -time dynamic linking? What you say makes complete sense to me for load-time linking. My mistake - I didn't mention how the Logger DLL was going to be used in the question. The application was going to load/unload it at run-time – Penoyer

@Raja: Yes -- if you link at run time using LoadLibrary & GetProcAddress, the .lib file isn't used (and often won't be present at all). – Mclemore

Ah - but i see it nevertheless. I was wondering why it would ever be needed, and how I could tell visual studio to not make one. – Penoyer

@Raja: I don't know of an easy way to tell VS to not create it. It also normally creates a .exp file you normally won't need either (unless you have a circular dependency). I suppose if you really want them gone, you could add a post-build step to delete them, but I've never bothered. – Mclemore

Thanks for taking the time to clarify everything Jerry. Appreciate it! – Penoyer

Answer 2

An exe that uses your logger.dll is going to need to link to logger.lib. Without the lib the exe cannot be built. The lib contains stub functions that satisfy the calls made by exe code. (At runtime the stubs transfer the calls into the DLL.)

Bacteriolysis

Wouldn't that depend on the way the DLL is loaded, i.e. static loading (header file contains a bunch of imports) v/s dynamic loading and getting the function pointers at run time. I don't see why the latter needs the .lib to build the EXE. – Penoyer

Correct. If you get the function pointers at run time you don't need the .lib. That is like doing the linking yourself in code instead of compiling calls and letting the linker do it. Your question was why is the lib file created: It is created so exe files can resolve ordinary calls to DLL functions. – Bacteriolysis