[PATCH] fix runtests to set LD_LIBRARY_PATH environment variable

[Karel Gardas]

One note: I've tested manually relink libHSrts-ghc7.7.20130126.so and 
added -v -optl=-v -optl=-Wl,-rpath 
-optl=-Wl,$HOME/vcs/ghc-src/ghc-head/rts/dist/build to its params and as 
expected this works fine. RTS lib knows where to find libffi and 
testsuite is happy.

Thanks,
Karel

On 01/26/13 07:46 PM, Karel Gardas wrote:
>
> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>