We should probably just go ahead with that fix anyways since this breakage is rather severe. Let's keep this ticket open after doing so
#10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+----------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by trommler): Replying to [comment:6 rwbarton]: though, to see whether it causes any issues like #8935 and perhaps take a moment to see if we can find a simpler way to handle this whole situation. The issue in #8935 was that we did not search the global context (the executable) first when resolving a symbol. The issue were certain relocations used for global variables (the process environment in the case of #8935). To solve the issue here we have two options: 1. Load C libraries with RTLD_GLOBAL, the symbols cannot be overridden by Haskell code. Is there a reasonable use case where we would override the definition of a symbol in a C library during one run of GHCi? 1. Append all `-lfoo` to every link command of a temporary shared library. If a symbol is defined in a library mentioned earlier in the link command it will override the symbol in `libfoo`. The second option is probably easier to implement whereas the performance of the first option will most likely be better (fewer libraries to open and fewer symbols to look at). I would say we go for option two for now and create a new ticket for a complete redesign of dynamic linking for 7.12. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10458#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler