why do I need to link a lib file to my project?

问题:

I am creating a project that uses a DLL. To build my project, I need to include a header file, and a lib file. Why do I need to include the respective lib file? shouldn't the header file declare all the needed information and then at runtime load any needed library/dll?

Thanks

回答1:

In many other languages, the equivalent of the header file is all you need. But the common C linkers on Windows have always used import libraries, C++ linkers followed suit, and it's probably too late to change.

As a thought experiment, one could imagine syntax like this:

__declspec(dllimport, "kernel32") void __stdcall  Sleep(DWORD dwMilliseconds);

Armed with that information the compiler/linker tool chain could do the rest.

As a further example, in Delphi one would import this function, using implicit linking, like so:

procedure Sleep(dwMilliseconds: DWORD); stdcall; external 'kernel32';

which just goes to show that import libraries are not, a priori, essential for linking to DLLs.

回答2:

No, the header file isn't necassarily enough. The header file can contain just the declarations of the functions and classes and other things you need, not their implementations.

There is a world of difference between this code:

void Multiply(int x, int y);

and this code:

void Multiply(int x, int y)
{
   return x * y;
}

The first is a declaration, and the second is a definition or implementation. Usually the first example is put in header files, and the second one is put in .CPP files (If you are creating libraries). If you included a header with the first and didn't link in anything, how is your application supposed to know how to implement Multiply?

Now if you are using header files that contain code that is ALL inlined, then you do not need to link anything. But if even one method is NOT inlined, but has its implementation in a .CPP file that is compiled to a .lib file, than you need to link in the .lib file.

[EDIT] With your use of Import Libraries, you are telling the linker to NOT include the implementation details of the imported code into your binary. Instead the OS will then load the import DLL at run-time into your process. This will make your application smaller, but you have to ship another DLL with it. If the implementation of the library changes, you can just reship another DLL to your customers, and not have to reship the entire application.

There is another option where you can just link in a library and you don't need to ship another DLL. That option is where the Linker will include the implementation into your application, making it bigger in size. If you have to change the implementation details in the imported library, then you have to recompile and relink your entire application, and reship the entire thing to your customers.

回答3:

That is a so-called "import library" that contains minimal wiring that will later (at load time) ask the operating system to load the DLL.

回答4:

DLLs are a Windows (MS/Intel) thing. The (generated) lib contains the code needed to call into the DLL and it exposes 'normal' functions to the rest of your App.

回答5:

There are two relevant phases in the building process here:

• compilation: from the source code to an object file. During the compilation, the compiler needs to know what external things are available, for that one needs a declaration. Declarations designed to be used in several compilation units are grouped in header. So you need the headers for the library.

• linking: For static libraries, you need the compiled version of the library. For dynamic libraries, in Unix you need the library, in windows, you need the "import library".

You could think that a library could also embed the declarations or the header could include the library which needs to be linked. The first is often done in other languages. The second is sometimes available through pragmas in C and C++, but there is no standard way to do this and would be in conflict with common usage (such as choosing a library among several which provide code variant for the same declarations, for instance debug/release single thread/multithreads). And neither choice correspond well with the simple compilation model of C and C++ which has its roots in the 60's.

回答6:

The header file is consumed by the compiler. It contains all the forward declarations of functions, classes and global variables that will be used. It may also contain some inline function definitions as well.

These are used by the compiler to give it the bare minimum information that it needs to compile your code. It will not contain the implementation details.

However you still need to link in all the function, and variable definitions that you have told the compiler about. Failure to do so will result in a linker error. Often this is contains in other object files which may be joined into a single static library.

In the case of DLLs (or .so files), we still need to tell the linker where in the DLL or shared object the missing symbols are. On windows, this information is contained in a .lib file. This will generate the code to load and link the code at runtime.

On unix the the dll and lib files are combined into a single .so file which you must link against to about linker errors.

You can still use a dll without a .lib file but you will then have to load and link in all the symbols manually using operating system APIs.

回答7:

from 1000 ft, the lib contains the list of the functions that dll exports and addresses that are needed for the call.