Dynamic libraries and GHCi

[Simon Marlow]

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.
>>
>> Basically there's a fair bit to do to make a dynamic GHCi a reality, and
>> before we can do anything there are some tricky decisions to make.
>>
>
> 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.

Cheers,
	Simon