On Mon, Jan 11, 2010 at 04:32:02PM +0000, Duncan Coutts wrote: > 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.
Why is this useful? I can't imagine a reason for wanting several copies of exactly the same ghc around, that would not be better served by changing the version on one of them at build time. In any event, you could always install them into arbitrary private locations. I don't think there is a use case for multiple instances of exactly the same version installed into the global search paths for applications to use. > It lets you install > ghc or a package into any test prefix and have things work. Not relevant since those would just be the degenerate case of an installation into some arbitrary private location, which would either be added to the search path manually, or rpathed. > It also lets > us make a completely relocatable ghc installation. No... it's the only thing that requires you to use rpath, which is precisely the bit that makes the installation non-relocatable. Placing the .so files directly in /usr/lib or some other directory in the search path would be how you 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. Given the number of other files that are spread around the filesystem, I find it hard to believe this is a real goal. > > /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. Since static libraries are not required at runtime, it makes no difference where you put them - no advantage, one location is as good as any other. > > 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). Arbitrary definitions of 'neatness' are not a concern here, no. Only relocatable objects. > > > 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. No, integrating your private builds into the system search path is preferable because it makes them relocatable, and using LD_LIBRARY_PATH is the way you're supposed to do that. This is mandatory for those of us who have home directories that exist in more than one fixed location (typically, because they're a network mount on heterogenous systems). rpath will not work here. > > > 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 This works only if the libraries and binaries are installed into a nextstep-style application bundle (for use as private libraries). It is useless if, for example, you had a system with a global directory where shared libraries are installed (say, /usr/lib) and want to build a binary in a private location that is not fixed relative to that directory (say, $HOME/bin). Such systems would appear to be common, since that's all the unix-like systems. > Of course you cannot > relocate individual bits, but you don't want to do that. I want to do that. That's the common case. Application bundles with private libraries are really really rare (macosx is about the only place you'll find them nowadays, and even there they've mostly switched to using shared libraries). To reiterate, this is the exemplar use case for relocatable objects: Install ghc and some libraries to /usr/local/ Build some applications with ghc and install them into /home/asuffield/bin/ mv /usr/local/lib/*ghc* /srv/nfs-app-server/lib/ mv /home/asuffield /home/a/asuffield At this point, all previously compiled binaries should continue to work without any intervention from the user. If they do not use rpath, then they *do* work. (There are many degenerate forms of this case which are arguably more important - such as vendor upgrade paths - this one is picked for clarity and to exercise all aspects of the problem) _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
