ANNOUNCE: GHC 7.8.1 Release Candidate 1

Christiaan Baaij christiaan.baaij at
Wed Feb 5 15:46:57 UTC 2014

On Feb 5, 2014, at 3:26 PM, Ryan Newton <rrnewton at> 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 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 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?


More information about the Glasgow-haskell-users mailing list