Add Windows import library support to the Runtime Linker

Summary:
Import libraries are files ending in `.dll.a` and `.lib` depending on which
compiler creates them (GCC, vs MSVC).

Import Libraries are standard `archive` files that contain object files.
These object files can have two different formats:

1) The normal COFF Object format for object files
    (contains all ascii data and very little program code, so do not
     try to execute.)
2) "short import" format which just contains a symbol name and
   the dll in which the symbol can be found.

Import Libraries are useful for two things:

1) Allowing applications that don't support dynamic linking to
   link against the import lib (non-short format) which then
   makes calls into the DLL by loading it at runtime.

2) Allow linking of mutually recursive dlls. if `A.DLL` requires
   `B.DLL` and vice versa, import libs can be used to break the cycle
   as they can be created from the expected exports of the DLLs.

A side effect of having these two capabilities is that Import libs are often
used to hide specific versions of DLLs behind a non-versioned import lib.

e.g. GCC_S.a (non-conventional import lib) will point to the correct
`libGCC` DLL. With this support Windows Haskell files can now just link
to `-lGCC_S` and not have to worry about what the actual name of libGCC is.

Also third party libraries such as `icuuc` use import libs to forward to
versioned DLLs. e.g. `icuuc.lib` points to `icuuc51.dll` etc.

Test Plan:
./validate

Two new tests added T11072gcc T11072msvc

Two binary files have been added to the test folder because the "short"
import library format doesn't seem to be creatable via `dlltool`
and requires Microsoft's `lib.exe`.

Reviewers: bgamari, RyanGlScott, erikd, goldfire, austin, hvr

Reviewed By: RyanGlScott, erikd

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1696

GHC Trac Issues: #11072

0 files changed, 0 insertions, 0 deletions