#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