Know If .Lib Is Static or Import

know if .lib is static or import

Use the lib command. If it's static, lib will show you a pile of .obj files inside. Not so if it's am implib.

lib /list foo.lib

will do it.

Also see:

https://learn.microsoft.com/en-us/cpp/build/reference/managing-a-library

How to See the Contents of Windows library (*.lib)

Assuming you're talking about a static library, DUMPBIN /SYMBOLS shows the functions and data objects in the library. If you're talking about an import library (a .lib used to refer to symbols exported from a DLL), then you want DUMPBIN /EXPORTS.

Note that for functions linked with the "C" binary interface, this still won't get you return values, parameters, or calling convention. That information isn't encoded in the .lib at all; you have to know that ahead of time (via prototypes in header files, for example) in order to call them correctly.

For functions linked with the C++ binary interface, the calling convention and arguments are encoded in the exported name of the function (also called "name mangling"). DUMPBIN /SYMBOLS will show you both the "mangled" function name as well as the decoded set of parameters.

Find out whether a lib requires static or dynamic runtimes

dumpbin /directives is your friend:

C:\jm>type 08.cpp
int main() { }

C:\jm>cl /nologo /c /MT 08.cpp
08.cpp

C:\jm>dumpbin /nologo /directives 08.obj

Dump of file 08.obj

File Type: COFF OBJECT

   Linker Directives
   -----------------
   /DEFAULTLIB:LIBCMT
   /DEFAULTLIB:OLDNAMES

  Summary

          60 .debug$S
          2F .drectve
           7 .text$mn

C:\jm>

Note the /DEFAULTLIB:LIBCMT under "Linker Directives." This linker directive is injected into the object when you compile with /MT (static release CRT). The /MT, /MTd, /MD, and /MDd linker options all cause different runtime libraries to be dragged in. See the documentation for details.

A library is just a collection of objects, so you can use dumpbin /directives on a lib file to get the directives contained in each object in the library. Note that it's possible (though quite uncommon) for different objects in a single static library to be compiled with different runtime library options.

C++ how to tell if static .lib is valid, callable from external code

On Windows, shared libraries and LoadLibrary are associated with the file extension .dll.

.lib suggests that you should try static linking, like a linux .a file. .lib files may contain actual code, but are also used for an import library, such that static linking will generate a binary that requires a DLL at runtime.

DLL and LIB files - what and why?

There are static libraries (LIB) and dynamic libraries (DLL) - but note that .LIB files can be either static libraries (containing object files) or import libraries (containing symbols to allow the linker to link to a DLL).

Libraries are used because you may have code that you want to use in many programs. For example if you write a function that counts the number of characters in a string, that function will be useful in lots of programs. Once you get that function working correctly you don't want to have to recompile the code every time you use it, so you put the executable code for that function in a library, and the linker can extract and insert the compiled code into your program. Static libraries are sometimes called 'archives' for this reason.

Dynamic libraries take this one step further. It seems wasteful to have multiple copies of the library functions taking up space in each of the programs. Why can't they all share one copy of the function? This is what dynamic libraries are for. Rather than building the library code into your program when it is compiled, it can be run by mapping it into your program as it is loaded into memory. Multiple programs running at the same time that use the same functions can all share one copy, saving memory. In fact, you can load dynamic libraries only as needed, depending on the path through your code. No point in having the printer routines taking up memory if you aren't doing any printing. On the other hand, this means you have to have a copy of the dynamic library installed on every machine your program runs on. This creates its own set of problems.

As an example, almost every program written in 'C' will need functions from a library called the 'C runtime library, though few programs will need all of the functions. The C runtime comes in both static and dynamic versions, so you can determine which version your program uses depending on particular needs.

Can an import library contain both stubs and static code at the same time?

There's no technical reason that an import library can't contain statically linked entry points.

You'd want to check whether this works properly, but one way that might get you there is to do a postprocess step on the import library to add the static linked objects to it.

This page includes the following notes:

You can use LIB to perform the following library-management tasks:

• To add objects to a library, specify the file name for the existing library and the filenames for the new objects.

Provided this operation doesn't remove the DLL import information, it should allow you to create such a library. I'm at work right now, on a Mac, so I don't have access to VS on my Windows system at home to test this for sure.

As to how the linker knows the name of the DLL involved, that's embedded in the import library, and from there gets embedded into the final EXE.

why there is a .lib file when create dynamic .dll file?

It has to do with the difference between "implicit" linking and "explicit" linking. The one sentence answer to your question is that that .lib file, often called a "stub lib" and officially called an "import library", is necessary when you do implicit linking but not otherwise.

In implicit linking, at compile time the compiler generates external function references for calls into the DLL, then the linker needs to link those to something: it uses the import library to help it do that. The linker treats these calls as special cases; it inserts code in the executable file for finding the DLL and for calling into the DLL for specific functions.

From the point-of-view of the programmer, implicit linking behaves like static linking except the DLL needs to be somewhere where the system can find it when the application is run or the system will pop up an error dialog at application startup.

Explicit linking means that it is the programmer's responsibility to find and load the DLL and to know what functions are in the DLL and how to call into them. See LoadLibrary and GetProcAddress for details. Explicit linking is useful if usage of a library is conditional or for applications with plugin architectures in which the actual DLLs to be used may not even be known at compile time.

In general though, if implicit linking does what you need, it is easier to just do it that way.

Creating static libraries and static linking with MSVC Build Tools on Windows

Ok, after further exploration, it seems I have the answers.

The first question was asked here before here, and there is an interesting comment related to libraries created with MinGW (one more relevant MinGW-related question). There are several options, and the simplest appears to be lib /list sqlite3.lib, which should list objects for a static library and produce no output for the import library.

The answer to the second question is given by Misrosoft, stating that

The default mode for LIB is to build or modify a library of COFF objects. LIB runs in this mode when you do not specify /EXTRACT (to copy an object to a file) or /DEF (to build an import library).

The third question was discussed before here, and it appears that the answer is "yes". Come to think of it, a static library should contain the actual objects and no information about a DLL (which could have been created independently). The lib file is not good for use at run-time either way, so the only possibility for successful linking against static libraries should be the static mode.

---

Related Topics