[PATCH] fix runtests to set LD_LIBRARY_PATH environment variable

Karel Gardas karel.gardas at centrum.cz
Sat Jan 26 19:46:22 CET 2013


Hi Ian,

On 01/26/13 01:35 AM, Ian Lynagh wrote:
>
> Hi Karel,
>
> On Fri, Jan 25, 2013 at 08:12:53PM +0100, Karel Gardas wrote:
>> On 01/25/13 09:02 AM, Simon Marlow wrote:
>>> Hold on a minute. Why do you need to set LD_LIBRARY_PATH? It should be
>>> unnecessary because the binaries are linked with -rpath options so they
>>> can find their libraries.
>>
>> it's simple, every lib is rpath-ed except the libffi. See:
>
> I think the right thing to do is to use rpath to find libffi too. I've
> reverted the testsuite patch.

OK! So before going into DriverPipeline.linkBinary business I'd like to 
ask you intended behavior of this. The current behavior is:

1) libffi is linked to rts lib, i.e. libHSrts-ghc7.7.*.so

2) libffi is not linked into application binary

Now, are both of those points right? Or better do you agree that the 
implementation will behave in this way? If so, then 
DriverPipeline.linkBinary does not need to deal with libffi at all 
probably, but we will need to change a way how we link 
libHSrts-ghc7.7.*.so (add rpath to libffi there) and we will also need 
to relink it during the installation step (to add target dir rpath of 
libffi again). Do you agree with this?

Another option might be to link libffi into target application binary 
with all the rpath machinery in place like is used in case of other 
haskell/rts libraries. This way, we do not need to change the 
installation to relink rts lib, but will need to fix 
DriverPipeline.linkBinary probably to include libffi there.

What's your opinion on this?

Thanks a lot!
Karel



More information about the ghc-devs mailing list