On Sun, 2010-01-10 at 21:22 +0000, Andrew Suffield wrote: > 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/).
Right it's currently using the package and ghc version in there because the previous plan was to install everything in /usr/lib by default. > 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 It's true that such a layout can work. The question is should we install into a global location by default if we don't actually have to. There are advantages to not doing so. In particular multiple instances of the same version of a package, or multiple instances of the same ghc version can co-exist happily if they're isolated. It lets you install ghc or a package into any test prefix and have things work. It also lets us make a completely relocatable ghc installation. In the absence of a proper package manager it's also an advantage in identifying which files need to be deleted to uninstall. > /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/... So why have we been using isolated locations for the static libs all this time? There must be some advantage. > 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? I was thinking that installing into /usr/lib counts as scattering .so files. :-) If we're talking about "neatness" then having most package files under a couple dirs named after the package seems preferable (and is still FSH compliant). > > 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. Right. We cannot expect random users to set up an LD_LIBRARY_PATH. It's bad enough with the problems with the $PATH for programs cabal installs. Also, if we're ranking "badness" then surely LD_LIBRARY_PATH ranks as more of a hack last resort than does rpath. > > 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). Huh? The program and the libs can use $ORIGIN. $prefix/bin/foo has -rpath '$ORIGIN/../lib' to find libfoo $prefix/lib/libfoo.so has -rpath '$ORIGIN' to find libbar $prefix/lib/libbar.so So I can have a binary installer that plonks the whole lot anywhere and it works (or run off some removable media). Of course you cannot relocate individual bits, but you don't want to do that. > 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. Right, you cannot move the libs relative to the progs. If you want to do that then you need to go back to using LD_LIBRARY_PATH or global search paths. On the other hand, if you install the libs in fixed locations then you can relocate the binary ok. That is the current default. Making self-contained relocatable bundles using ORIGIN is a separate step. > 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. As I said, if a distro wants to put everything in /usr/lib then that's fine and we should support it. > > 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. Currently we must reinstall the world when libs change. This is because there is no stable ABI. If/when we support stable ABIs and upgrading without rebuilding then we'll need to adjust the SONAME / rpath scheme to take account of that. > > 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. We will have to stop using the package version and ghc version in the SONAME. Instead it will have to be some encoding of the ABI. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
