C: Correct Way to Statically / Dynamically Link with MinGW-w64

The Answer:

MinGW / MinGW-w64's port of GCC's linker ld can:

• directly link to .dlls for dynamic linking
• indirectly link to .dll.as for dynamic linking (using import library at compilation)
• link to .as 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 .dlls 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:

1. .so for shared libraries on Linux because that's what the GCC binutils' linker searches for,
2. or .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:

1. An import library generated by the compiler from a .dll with all needed definitions for symbol resolution during compilation (however, function implementations are left out) [2]
   1. If you attempt to generate import libraries for a 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
2. A fully-defined static library

.libs serve a dual purpose because, as @ChronoKitsune commented, the MSVC linker does not directly link against .dlls. 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 use ar -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.