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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
