On Feb 5, 2014, at 3:26 PM, Ryan Newton <rrnew...@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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users