On Mon, 2010-01-11 at 20:19 +0000, Andrew Suffield wrote: > 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.
You've really no right to expect this to work (and indeed it will not unless you use LD_LIBRARY_PATH). This is not a mode supported by any "./configure --prefix" style system. You're supposed to provide the prefix of the final install location. Alternatively, some packages support being prefix independent. But that does not mean you can move all of the dependencies of the prefix-independent package around and expect it to work. In any case, using rpath does not mean you cannot override it with LD_LIBRARY_PATH (see ELF runpath vs rpath), so if you really want to do such things then it might still work. It's only might of course since packages also often need to know their installation prefix to find libexec progs, or data files. Though again if packages are using Cabal's Paths module then even these locations can be overridden using env vars. As I mentioned, the current default setup means that you can move the binaries around (ignoring issues related to data files), so long as you don't also move the libs. And if you do move the libs too then you can use an LD_LIBRARY PATH, which you would have to do anyway if you're moving things out of /usr/local/lib. Duncan _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
