On Sun, Jan 10, 2010 at 07:11:43PM +0000, Duncan Coutts wrote: > 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.
This does not appear to be an issue because the .so files are uniquely named by version and ABI. libHSbase-3.0.3.2-ghc6.12.1.so and libHSbase-4.2.0.0-ghc6.12.2.so can happily coexist in /usr/lib (unlike all the other stuff, which does belong in /usr/lib/ghc-$VERSION/). To be clear, I'm thinking of a layout like this: /usr/lib/libHSrts-ghc6.12.1.so /usr/lib/libHSbase-3.0.3.2-ghc6.12.1.so /usr/lib/libHSbase-4.2.0.0-ghc6.12.1.so /usr/lib/libHSrts-ghc6.12.2.so /usr/lib/libHSbase-3.0.3.2-ghc6.12.2.so /usr/lib/libHSbase-4.2.0.0-ghc6.12.2.so /usr/lib/ghc-6.12.1/libHSrts.a /usr/lib/ghc-6.12.1/base-3.0.3.2/... /usr/lib/ghc-6.12.1/base-4.2.0.0/... /usr/lib/ghc-6.12.2/libHSrts.a /usr/lib/ghc-6.12.2/base-3.0.3.2/... /usr/lib/ghc-6.12.2/base-4.2.0.0/... I can't think of any use cases where this would break stuff, and obviously it doesn't need rpath. Are there any other reasons for scattering the .so files? > It's also the only option for per-user > installations. Not necessarily, I have $HOME/lib in my LD_LIBRARY_PATH. rpath is a reasonable default here, though. > ELF supports isolated installations perfectly well using > rpath (and indeed relocatable libs using $ORIGIN). There's nothing icky > about using rpath. $ORIGIN is one of the several often-suggested attempts at solving the problems with rpath that doesn't help, and makes the problem worse because then your binaries aren't relocatable either (which makes sysadmins cry). So far as I'm aware, the only use case for it is nextstep-style application bundles, where /opt/$foo/bin/bar links to /opt/$foo/lib/libbaz.so for all $foo, and nothing outside /opt/$foo ever links to the object. It doesn't do anything useful for global shared library systems, where the use case is to link /home/foo/bin/bar to /usr/lib/baz/libbaz.so and then relocate the binary to /home/quux/bin/bar and the library to /usr/lib32/baz/libbaz.so. Bottom line is, relocatable libraries requires the use of rpath-free binaries, and hence vendors that do in-place binary upgrades (ie, Debian-style rather than reinstallation) have to avoid rpath or face serious problems later on when they need to relocate the libraries; there are no other solutions. It's not an issue for installations from source or systems that use a reinstall-the-world approach rather than in-place upgrades, as they have no need to relocate things. > 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. Since neither of these things attempts to provide an upgrade path (you're just expected to reinstall the world when the libraries change), they don't need to be relocatable - but it would be nice if they were. > and exactly what to put into the SONAME when we > install to a shared location will have to change when we support ABI > upgrades. Don't think that's going to be a problem. The current namespace is nicely distinct. _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
