[GHC] #8266: Dynamic linking on Mac

[GHC]

#8266: Dynamic linking on Mac
--------------------------------------------+------------------------------
        Reporter:  kazu-yamamoto            |            Owner:
            Type:  bug                      |           Status:  patch
        Priority:  highest                  |        Milestone:  7.8.1
       Component:  Build System             |          Version:  7.7
      Resolution:                           |         Keywords:
Operating System:  MacOS X                  |     Architecture:
 Type of failure:  GHC doesn't work at all  |  Unknown/Multiple
       Test Case:                           |       Difficulty:  Unknown
        Blocking:                           |       Blocked By:
                                            |  Related Tickets:
--------------------------------------------+------------------------------

Comment (by darchon):

 I guess I should have articulated better that the patch for Cabal is _not_
 needed for everything to work. The reason for the Cabal patch is simply:
 * Uniformity between `install_name`s of dynamic libraries supplied by GHC
 and those installed with Cabal.

 The new GHC patch adds an `LC_RPATH` command for every dependent library,
 pointing to the directory that the dependent library is installed in. So
 if a library is linked against, e.g.,
 `@rpath/libHSbase-4.7.0.0-ghc7.7.20140103.dylib`, it gets an `LC_RPATH`
 command that points to e.g. `/usr/local/ghc/lib/base-4.7.0.0/`.

 Now, _without_ the patch to Cabal, a library like `text` would get an
 `install_name` of `/Users/darchon/.cabal/lib/x86_64-osx-
 ghc-7.7.20140101/text-1.1.0.0/libHStext-1.1.0.0-ghc7.7.20140103.dylib`.
 Under the new patch, a library like `parsec` would be linked against
 `/Users/darchon/.cabal/lib/x86_64-osx-
 ghc-7.7.20140101/text-1.1.0.0/libHStext-1.1.0.0-ghc7.7.20140103.dylib`,
 but GHC would still add an `LC_RPATH` pointing to:
 `/Users/darchon/.cabal/lib/x86_64-osx-ghc-7.7.20140101/text-1.1.0.0`. Of
 course this `LC_RPATH` command is superfluous/bogus, as there isn't be any
 `@rpath` referenced dynamic library to be found there. I believe these
 superfluous `LC_PATH`s to be harmless though.

 Note that neither the GHC patch nor the Cabal patch intended to make
 packages/libraries relocatable. It essentially traded one direct/full path
 for another. In the pre-patch situation the `install_name` is a direct
 path, in the post-patch situation a library has an `LC_RPATH` that is a
 direct/full path.

 So, to sum up:
 * The new GHC patch solves the original issue of having the GHC build-dir
 referenced in built/distributed libraries, while also supporting the use-
 case of building/installing packages using `cabal-install` and the
 `inplace/bin/ghc-stage2`.
 * The Cabal patch only add uniformity between `install_names`, but is not
 necessary for a correctly working GHC/Cabal system.

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