This post originates from one quest for using one
.lib file in
will hopeful help others on the same path. The mechanics used in different OSes
is not exactly the same, so the discuss is divided into two categories.
A static library usually has one
.a extension. When being used in linking
process, only the object files used will be linked to the target by default, and
this behavior could be turned off by
--no-whole-archive. Audience is
encouraged to read the manual of
ld for this.
A dynamic library usually has the
.so (share object) extension. During
linking, no actual code and data is copied to the target. Instead, only one slot
is created for run time loading.
The extension for static library is
.lib in Windows. Other than the renaming,
there’s not much effective difference to my knowledge. The case for dynamic
libraries is a bit more complex. Dynamic libraries have
.dll (Dynamic Linking
An import library is a library that automates the process of loading and using a dynamic library. On Windows, this is typically done via a small static library (.lib) of the same name as the dynamic library (.dll). The static library is linked into the program at compile time, and then the functionality of the dynamic library can effectively be used as if it were a static library. On Linux, the shared object (.so) file doubles as both a dynamic library and an import library.
With the background knowledge on static and dynamic libraries, we are ready to understand the two approaches to this problem.
There are two main types of DLL:
Unmanaged DLL (native DLL): used with
dllimportin C# project.
Managed DLL: using C++/CLI language as the wrapper for native code.
The two approaches are documented in detail at
The conclusion drawn by the author seems sensible that
unmanaged approach puts
the burden on of users of this new DLL, while the
managed approach puts the
burden on the creator of this new DLL.