#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