However, if the comment:1 issue isn't fixed, I think there's more work to be done here, no? I would like to open a new ticket for the issue in comment:1 because I
#10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Runtime System | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:12 goldfire]: think it is a different issue. The undefined symbol in this ticket is in another package whereas in comment:1 it is found in one of the objects of the current package. That symbol, however, should be resolvable by linking with the previous temporary shared object and following the chain of links to the module where the symbol is defined. My current hypothesis is some Linux distributions modify the defaults of GNU `ld` (and perhaps Gold) and that is responsible for the undefined symbol. The fix that I have in mind involves checking for a link editor flag called `--no-as-needed` (and it must be the link editor we use in the installed ghc) and then passing the correct flag to override the default. See: https://ghc.haskell.org/trac/ghc/ticket/9186#comment:26 for more details on that flag. The issue does not affect OSX. That would reduce the scope of the defect to only those systems that have a modified` ld` , i.e. some Linux distributions. I'll create a new ticket with more details tomorrow. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10058#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler