Intuitively:
.dll
(dynamic linking) / .lib
(static linking)..so
/ .a
binaries are required.What I've Found:
.dll
s and .a
s
.so
and statically link to .a
..lib
and another on SO says it doesn't work. Unfortunately, I can't find explicit documentation from MinGW & MinGW-w64 that says what's right and what's wrong when dynamically/statically linking libraries.
In my experience, I have always been able to dynamically link to .dll
s. Once, I was able to statically link to a .lib
(using the -static
flag).
Question:
Are .dll
/ .a
binaries appropriate to dynamically and statically link libraries when compiling with the MinGW-w64 GCC tool-chain? In other words, dynamic libraries generated for MSVC and static libraries generated for GCC?
The Answer:
MinGW / MinGW-w64's port of GCC's linker ld
can:
.dll
s for dynamic linking.dll.a
s for dynamic linking (using import library at compilation).a
s for static linking.Why does MinGW / MinGW-w64's port of the GCC linker look for .dll
?
In short, the best answer is because that's .dll
s are Microsoft's answer for shared objects on their 32-bit and 64-bit operating systems. On Windows, MinGW / MinGW-w64's port uses Microsoft C runtime (msvcrt.dll
) [1], so it obeys Windows OS linker rules.
Dynamic-link library (or DLL) is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems. -- From Wikipedia
So, to dynamically link libraries you'll use the file extension:
.so
for shared libraries on Linux because that's what the GCC binutils' linker searches for,.dll
for shared libraries on Windows because that's what the MinGW / MinGW-w64 port of GCC binutils' linker searches for.The extension used by the MinGW port of GCC for shared library objects is explicitly listed in a cygming
file in the source code. As @ChronoKitsune commented, specifically: SHLIB_EXT = .dll
in libgcc/config/i386/t-slibgcc-cygming
. The cygming
files (for Cygwin and MinGW) are common to MinGW, MinGW-w64, and both 32-bit and 64-bit versions of Cygwin. Therefore, this is true for all ports of the GCC binutils to Windows.
Why does the MinGW / MinGW-w64 linker handle .lib
then?
In principle, the GCC binutils' linker won't recognize a .lib
as a static library. However, it is possible that the linker is smart enough to link against the .dll
that a .lib
imports (in the case that the .lib
is actually an import library). For instance, in the case that a library has dependencies which are linked dynamically that library will be linked dynamically (and flags to "force" static linking will be ignored).
In such cases, I'd imagine that the linker would not throw any errors and it would appear as though the .lib
was actually linked successfully.
How do import libraries work? (freebie)
On Windows, a .lib
can be one of two libraries:
.dll
with all needed definitions for symbol resolution during compilation (however, function implementations are left out) [2]
xxxx.dll
with MinGW / MinGW-w64's port of GCC binutils, it will produce a libxxxx.dll.a
. The extension file extension is useful for distinguishing an import library from a fully-defined static library. When compiling with MSVC, this distinction isn't apparent in the extension
.lib
s serve a dual purpose because, as @ChronoKitsune commented, the MSVC linker does not directly link against .dll
s. Instead, an import library is necessary to resolve symbol definitions at compilation, so that the .dll
is not loaded until run-time:
An import library (.LIB files) to link with. (The linker creates the import library when the DLL is built.) -- VS 2015 Documentation
Why does MinGW/ MinGW-w64's port of the GCC linker look for .a
?
This is simple - the port make use of the ar
archiving utility that is used on *-nix systems, as @ChronoKitsune commented:
The extension for static libraries comes from the
ar
(archive) program included with binutils. You can usear -t libxxx.a
to list the object files contained within any static library.
This is similar to the lib
command for MSVC, lib /list foo.lib
This command will return a list of .obj
files inside if the .lib
is a static library.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With