Executables built by GHC 7.8.2 need to have DYLD_LIBRARY_PATH set in a wrapper

[jwiegley]

For example, cabal-bounds now has the following dylib reference:

Hermes:~ $ cabal-bounds
dyld: Library not loaded: @rpath/libHScabal-bounds-0.4.1-ghc7.8.2.dylib
  Referenced from: /Users/johnw/.nix-profile/bin/cabal-bounds
  Reason: image not found
Trace/BPT trap: 5

If I set DYLD_LIBRARY_PATH to point into the right directory in the Nix store, it works fine:

export DYLD_LIBRARY_PATH=/nix/store/pgrgcbs5g6d53zw0hmg1dm20ggbjcgm3-haskell-cabal-bounds-ghc7.8.2-0.4.1-shared/lib/ghc-7.8.2/cabal-bounds-0.4.1
hermes:~ $ cabal-bounds
No mode given and no default mode

[peti]

5849a91 changed the default builder to set

configureFlags+=" --ghc-option=-optl=-Wl,-rpath=$out/lib/${ghc.ghc.name}/${self.pname}-${self.version}";

on Linux. I guess, we'll need something similar for Darwin, too. The problem seems to be, though, that Darwin's ld doesn't accept -rpath the way Linux does. What would be the proper way to configure a run-time search path at link-time on Darwin?

[peti]

According to http://stackoverflow.com/questions/4513799/how-to-set-the-runtime-path-rpath-of-an-executable-with-gcc-under-mac-osx, Darwin uses @rpath. Duh! Could you please verify whether changing that flag in pkgs/build-support/cabal/default.nix accordingly has a positive effect?

[jwiegley]

@peti No, that did not work. I just saw this failure today trying to run pandoc from the command-line:

Exception: dyld: Library not loaded: @rpath/libHSpandoc-1.12.4.2-ghc7.8.2.dylib
  Referenced from: /nix/store/plxmy5knqxs3vvh8hr2j8i570hsnmvxq-haskell-pandoc-ghc7.8.2-1.12.4.2-shared/bin/pandoc
  Reason: image not found

[peti]

I am sorry, but I cannot help much remedying this issue. I don't know much about Darwin, and I don't have access to that platform either. All I can do is disable shared library support on Darwin by default in the Cabal builder?

[jwiegley]

Yes, that would work. The alternative is to use install_name_tool to edit every library and executable generated from cabal to rewrite @rpath into an explicit path reference to the specified dependency.

[peti]

Well, if there is a way to fix shared library support on Darwin, I'd be more than happy to apply a patch. :-)

[jwiegley]

@peti I discovered what the underlying problem was:

When building an executable in a temporary directory, the rpath that get "baked in" refers to the directory of the dylib in that temp directory. You can see this by setting DYLD_PRINT_RPATHS=1 and then running an executable like pandoc.

What this patch does is to add another rpath after the executable is built: the directory where the dylib will be installed in the store. Previously, since this directory did not exist yet and we were not informing the linker of its location, there was no way for OS X to know that it should look for its dependencies there.