[GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X

[GHC]

#10322: In ghci object code loader, linking against the previous temp dylib is not
enough on OS X
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:  7.10.2
       Component:  Compiler          |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  MacOS X           |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:  Phab:D852
-------------------------------------+-------------------------------------

Comment (by George):

 Not sure but the -flat_namespace option might be what you are looking for.
 Following is from the Mac man page for ld. I wonder if ghc has always had
 this bug or if this is a regression.

 == Two-level namespace ==

 By default all references resolved to a dynamic library record the library
 to which they were resolved. At runtime, dyld uses that information to
 directly resolve symbols.  The alternative is to use the -flat_namespace
 option.  With flat namespace, the library is not recorded.  At runtime,
 dyld will search each dynamic library in load order when resolving
 symbols. This is slower, but more like how other operating systems resolve
 symbols.

 == Indirect dynamic libraries ==

 If the command line specifies to link against dylib A, and when dylib A
 was built it linked against dylib B, then B is considered an indirect
 dylib.  When linking for two-level namespace, ld does not look at indirect
 dylibs, except when re-exported by a direct dylibs.  On the other hand
 when linking for flat namespace, ld does load all indirect dylibs and uses
 them to resolve references.  Even though indirect dylibs are specified via
 a full path, ld first uses the specified search paths to locate each
 indirect dylib.  If one cannot be found using the search paths, the full
 path is used.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10322#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler