Dynamic libraries and GHCi

Brandon S. Allbery KF8NH allbery at ece.cmu.edu
Thu May 20 08:42:00 EDT 2010

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

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

brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100520/02b4a8f8/PGP.bin

More information about the Glasgow-haskell-users mailing list