Tamar Christina authored Jan 30, 2017 and Ben Gamari committed Jan 30, 2017

The symbol not found error that is triggered
during lazy-loading was a bit chaotic before.

This reformats it a bit to:

```
ghc-stage2.exe:  | E:\...\libLLVMSupport.a: unknown symbol `_ZN4llvm5APIntC1Ejyb'
ghc-stage2.exe:  | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm5APInt14AssignSlowCaseERKS0_'
ghc-stage2.exe:  | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm13ConstantRangeC1ENS_5APIntES1_'
ghc-stage2.exe:  | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm14FoldingSetImplC2Ej'
ghc-stage2.exe:  | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm15LLVMContextImplD1Ev'
ghc-stage2.exe:  | E:\...\libLLVMLTO.a: unknown symbol `_ZN4llvm11LLVMContextD1Ev'
ghc-stage2.exe:  | E:\...\libLLVMCore.a: unknown symbol `_ZNK4llvm5Value10getContextEv'
ghc-stage2.exe: ^^ Could not load 'LLVMIsMultithreaded', dependency unresolved.
See top entry above.
```

I have also thought about also showing the demangled names, as it may
be useful for the end user.

`libgcc` seems to provide a method for this so we wouldn't need any
extra dependency.

Any thoughts on this or would it not be useful?

Reviewers: austin, erikd, simonmar, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, thomie, #ghc_windows_task_force

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

GHC Trac Issues: #13093, #13113