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