My plan was to leave it in 7.8, but not used by default, and then to remove it from HEAD shortly after 7.8.1 is released. The goal is to stop

#8039: RTS linker: unloadObj() does not actually unload the code -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Replying to [comment:8 igloo]: maintaining the ghci linker, after all! I thought we had some platforms that didn't have dynamic linking support, e.g. ARM/Linux? I personally don't care if we get rid of the MACH-O support, and maybe even the COFF support from the linker. The ELF support is fairly solid though, and for the use case I'm interested in we don't run into any of the known limitations. Maybe I could use shared libraries. But (a) this is a scenario where dynamic linking is generally shunned because it creates more problems than it solves (deploying to large numbers of machines), (b) we really care about performance, and dynamic linking adds unnecessary overhead, and (c) we need to unload objects, and I don't know how to do that with shared libraries yet. I still buy the arguments for moving to dynamic linking for GHCi. But applications with plugin support is a use case we weren't really thinking about during that discussion, and I think the tradeoffs are different. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8039#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler