Dynamic libraries and GHCi

[John Lato]

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.

Apparently -rpath was only added in 10.5, so the former was previously
true also.  According to the ld manpage, -rpath only has an effect
when the library's load path begins with @rpath/, which seems to break
the usual OS X loading scheme so you then have to use -rpath.

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.

John

[1] http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html#//apple_ref/doc/man/1/dyld