[GHC] #12486: Investigate removing libGCC symbols from RtsSymbols.c

[GHC]

#12486: Investigate removing libGCC symbols from RtsSymbols.c
-------------------------------------+-------------------------------------
           Reporter:  Phyx-          |             Owner:
               Type:  task           |            Status:  new
           Priority:  normal         |         Milestone:  ⊥
          Component:  Runtime        |           Version:  8.0.1
  System (Linker)                    |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:  #11981
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 The RTS is currently re-exporting symbols from the C compiler runtime in
 `RtsSymbols.c`.

 How this works is that the Runtime linker is declaring that it can provide
 these symbols because it's been linked against the C compiler library
 itself. In essence it's providing pointers to it's own symbol table.

 This Is fine but has two downsides:

 1) We have to keep adding symbols to export anytime the underlying C
 compiler changes things or someone needs a new symbol from the library.

 2) User code that is linking explicitly against these libraries will
 probably generate a duplicate symbols error if it needs a symbol we have
 not yet exported but is in the same object file or dependency of a symbol
 we have exported.

 One solution would be to add `libgcc_s` to the dependencies of `ghc-prim`
 which is the package that seems to require them.

 This has two issues with it: `GCC_S` doesn't exist for llvm, so we need to
 somehow know which compiler we're compiling for.

 Secondly on Windows `GCC_S` is an import library with a non-standard name.
 (.a instead of .dll.a) and we currently cannot recognize it as such. We'd
 try to load it as a normal archive and end up trying to execute ascii as
 code.

 This task is to find a way to remove the need to export these symbols yet
 still work with both GCC and LLVM.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12486>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler