[GHC] #10458: GHCi fails to load shared object (the 'impossible' happened)

[GHC]

#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