Dynamic libraries and GHCi

John Lato jwlato at gmail.com
Thu May 20 11:24:23 EDT 2010

On Thu, May 20, 2010 at 1:42 PM, Brandon S. Allbery KF8NH
<allbery at ece.cmu.edu> wrote:
> On May 20, 2010, at 08:29 , John Lato wrote:
>> On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH
>> <allbery at ece.cmu.edu> wrote:
>>> On May 20, 2010, at 06:23 , Simon Marlow wrote:
>>>> On 18/05/2010 17:48, John Lato wrote:
>>>>>> From: Simon Marlow<marlowsd at gmail.com>
>>>>>>> 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

> 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.


More information about the Glasgow-haskell-users mailing list