On 01/01/10 00:54, Andrew Suffield wrote:
On Fri, Jan 01, 2010 at 01:38:58AM +0100, Lars Viklund wrote:
On Wed, Dec 30, 2009 at 06:29:23PM +0000, Andrew Suffield wrote:
I've been thinking about this. The only reason why rpath is needed is
because the .so files are being stuck in lib/ghc-$version/ instead of
going into lib/ directly. However, I can't see a good reason for doing
this. The ABI is already encoded in the soname, which rules out the
usual reason for this sort of thing. Is there one?
If not, the icky rpath stuff could all go away.
It would still be needed for people (like me) who do not install into
system-global directories but rather somewhere in ${HOME}, wouldn't it?
Heck, I've got systems where not even /usr/local/lib is in relevant
lookup paths.
Yes. It would just be downgraded to a build-time option, so vendors
(who tend to get things messed up by rpath) could ship it disabled,
while builds like this would still use it - but with a single rpath
entry, rather than dozens of directories.
We had a similar plan in the past, see e.g.
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-June/012740.html
and for background:
http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management
However, Duncan's recent work on shared libraries made it the default to
use -rpath. Unfortunately I don't recall exactly the rationale, perhaps
Duncan can comment. We ought to update the wiki to match the current
state of affairs too.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
