#9438: Dynamic GHCi doesn't support static libraries -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): Phab:D4589 #15032 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari It certainly *can* be implemented, but it really depends on how `DYNAMIC_GHC_PROGRAMS` is implemented. I haven't looked at the exact implementation but I would imagine, that in order for this to work, the .so must export all symbols as globals. I suspect (without looking) that ghc is linking the shared lib using `--whole-archive`. C static shared archives wouldn't be must of an issue. If you have no reference to the C code in your own code it doesn't matter if the symbols are not there. As you can't directly call C code anyway. static Haskell libraries are a different issue, loading a static archive would require all it's symbols to also be exported. Two libraries with the exact same z-encoded symbol names would produce a duplicate symbol error, while this need not be the case normally. This is why I *think* it's currently not supported. An obvious work-around would be to create multiple .so and link them in the same order as the static archives. So I think it can be supported, but will require a bit of changes to `DYNAMIC_GHC_PROGRAMS`. You'd also have to track these archives. It would be a bit annoying to recompile them on every scope change when they didn't change. A totally naive implementation would be a bit of a performance hit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9438#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler