Re: Dynamic libraries and GHCi

On Thu, May 20, 2010 at 1:42 PM, Brandon S. Allbery KF8NH wrote:

On May 20, 2010, at 08:29 , John Lato wrote:

...

On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH wrote:

...

On May 20, 2010, at 06:23 , Simon Marlow wrote:

...

On 18/05/2010 17:48, John Lato wrote:

...

...

From: Simon Marlow > > But currently there is one problem with "GhcShared=YES": with this > option, the stage-2 compiler gets linked dynamically but the > corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, > thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around > this by manually symlinking all the dynamic libraries to > ./inplace/lib > and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should > be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have -rpath).  This is another issue we need to resolve before we can switch to a dynamically-linked GHCi.

When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX?  I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1.

It was my understanding that OS X doesn't have -rpath from reading

http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management

and from what I remember Mac people saying in the past.  Or maybe they were just saying that -rpath is not the right thing on OS X because libraries themselves have paths baked in.

The latter.  Also, I'd recommend DYLD_FALLBACK_LIBRARY_PATH per Apple recommendations, as you can otherwise get weird results.

According to the dyld docs, it looks like -rpath is meant to be used as a last resort when other mechanisms aren't feasible.  In particular, "The use of @rpath is most useful when  you  have  a complex  directory structure  of  programs  and  dylibs  which can be installed anywhere, but keep their relative positions." [1]

I suppose I'd agree that it's best avoided on OSX if it can be helped.

Interesting, considering that Apple's recommended use case appears to be exactly what we're looking for.

In that case, maybe -rpath is the right thing to do? I don't know much about Apple's dev. guidelines, so I won't make any recommendations.

Oh, also?  @rpath isn't mentioned in dyld(1) on Leopard and is barely referenced in ld(1), which is why I missed it (and probably part of why -rpath was ignored).

At my most charitable, I'd describe Apple's docs for command-line tools incomplete at best. John