#10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Ultimately Cabal is doing something fragile here, by invoking ghc on only the Haskell sources, and not passing it the C sources or object files. If the Haskell source contains a Template Haskell splice that actually uses a function defined in a C source file then this can't possibly ever work. If there is a Template Haskell splice that uses another module from the current package that also happens imports a function from a C source file, this might work depending on the details of the linker. The temporary shared object loaded to run the splice will certainly contain an undefined symbol, but this may or may not be a problem. Relevant factors include * Whether the library is marked for lazy binding of functions (PLT references). If the binding is lazy, then the load will not fail and the Template Haskell splice runner will be able to use the shared library as long as it does not actually need to call the function in question. If the binding is not lazy then the load will fail (`Loading temp shared object failed: [...] undefined symbol: [...]`). Lazy binding is normally the default but in some hardened systems or build environments such as haasn's it is not. * Whether the foreign call refers to the C symbol by a PLT or GOT entry. GOT entries cannot be resolved at call time because the reference is not necessarily a call. Why would we call a C function through a GOT entry? Well if optimizations are not enabled then the code generator for an STG foreign call produces Cmm like {{{ _cJW::I64 = foobarbaz; call "ccall" arg hints: [] result hints: [] (_cJW::I64)(); }}} and to the backend this looks like a general reference to an object followed by an indirect function call. We can and probably should fix this but it doesn't fix the actual issue here. In my opinion it would make more sense for Cabal to just provide the C sources or object files to the ghc invocation. But also see https://github.com/haskell/cabal/issues/1738 which points out a problem with that idea. Should Cabal have two categories of C source files, one that consists of dependencies of the Haskell code and one that consists of source files that have foreign export stub headers as dependencies? I would think that since Cabal is intended for building Haskell libraries that the first category would be much greater... I don't know if it makes sense to do anything here in GHC besides being aware of the issue and setting `ghc-options: -optl-Wl,z,lazy` when building on systems where it is not the default as a workaround. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10761#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler