ANNOUNCE: GHC 7.8.1 Release Candidate 1

[Christiaan Baaij]

On Feb 5, 2014, at 3:26 PM, Ryan Newton <rrnewton at gmail.com> wrote:

> I had some similar problems and had to fiddle with my DYLD_LIBRARY_PATH so that ghc-related executables would see the libffi.dylib that comes with GHC before any of my system-wide installed libffi.dylib.
> 
> Why the permissive @rpath link for libffi.dylib if the GHC executables are supposed to come with their own?

See https://ghc.haskell.org/trac/ghc/ticket/8266 for more information about the dynamic linking on OS X.

The reason is two-fold:

- During development, the ghc binary, ghc-stage2, lives in 'TOP/inplace/lib/bin', while libffi lives in 'TOP/rts/dist/build'.
  When deployed, the ghc binary lives in 'TOP/lib/ghc-<version>/bin', while libff lives in 'TOP/lib/ghc-<version>/rts-1.0'.
  So, the relative paths differ during development and installation, meaning a hard-coded relative path was not an option.
- After some iterations, I decided to make OS X behave as much as Linux as possible.
  Meaning that I just added LC_RPATH's for every library location on which a binary depends.
  And every library on which binary depend is made @rpath-relative.
  
From the very bottom of the page https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html it was my understanding that LC_RPATH were considered first when searching dylibs that had a path starting with @rpath.

But apparently that is not the case?

Christiaan