#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]:
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 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