On Sat, 2010-01-02 at 13:47 +0000, Simon Marlow wrote: > 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.
Right. I think it's much more sensible to use isolated locations for installed library files. It makes it much easier to have multiple instances of things. It's also the only option for per-user installations. ELF supports isolated installations perfectly well using rpath (and indeed relocatable libs using $ORIGIN). There's nothing icky about using rpath. Now distros may, for whatever reason, want to have their system packages use /usr/lib for everything, and that's fine, we should be able to support that. However I don't think it's a sensible default for generic ghc binaries or for global or per-user libs installed via cabal-install. The management of shared libs certainly isn't completely settled yet. In particular supporting building relocatable libs + binaries. There's also the matter of how we deal with compatible ABI upgrades. Also, if we are doing isloated installs then we don't need to put the ghc version and hash into the SONAME, and exactly what to put into the SONAME when we install to a shared location will have to change when we support ABI upgrades. There's also the matter of linking to the rts (and making it possible to link to different instances of the rts, normal, threaded, debug, etc) Duncan _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
