At Tue, 12 Jun 2007 08:28:08 -0700, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote: > > Clemens Fruhwirth wrote: > > > To solve this little shortcoming, the ld-invocation could be delegated > > to GHC. "ghc -o libHSfoo.so Foo1.o Foo2.o". > > You'd presumably want this to be "ghc -shared", yes? > > It's definitely preferable to cook this knowledge into ghc, rather than > to have the smarts in Cabal. The advantage of keeping the knowledge in > GHC is that it's more decoupled, and it mirrors the behaviour people > expect from other compilers (this is what gcc does, for example).
Full ack. > > 3) Running programs > > > Let's see how libtool handles this situation. > > I would recommend against following libtool's lead in this area. > Libtool's fondness for cooking RPATH into binaries makes it very > difficult to deal with, because it's quite common for those binaries to > get installed and distributed, RPATH and all. RPATH should only be used > by a user who knows they have a large-calibre weapon pointed at their foot. Did I understand that correctly that you don't want to see binaries with rpath's pointing to install directories such as /usr/lib/gcc-6.6? So, this forces us to use a wrapper in all cases. > > I agree that the last scheme sounds a bit wild, but I argue that > > that's what ELF designers had in mind when they specified the INTERP > > header. > > Let's not go there, please :-) Such a move would be a big maintenance > problem in its own right, and would make a lot of extra work for people > packaging GHC for different distributions as they would need to cook up > hacks for e.g. local SELinux policies regarding special ELF attributes > and memory protections. Running i386 binaries on x86-64 platform basically does the same thing: switch the ELF program interpreter (ld-linux-x86_64.so.2 to ld-linux.so.2), so if these projects can't handle the full glory of the ELF specification then it's probably not our problem. Yes, I agree that this might not be the most trouble-free solution, but certainly it's the most flexible one. But, let's consider another approach before going in that direction: Push the responsiblity for maintaining dynamic library information to "ghc-pkg register". The custom ELF interpreter proposed above would basically cook information from package.conf into stuff like "ld.so --library-path <..>". We can play the game differently and prepare the information of package.conf when running ghc-pkg register, instead of delaying this to program startup. On way of digesting this information would be to collect all dynamic libraries in a single directory; either something haskell specific /usr/lib/ghc-6.6/dynlibs or even /usr/lib. If we start to create links from /usr/lib/libHSbase.so -> /usr/lib/ghc-6.6/libHSbase.so, we might even drop the wrapper. Other variants is to have ghc-pkg register <info-for-network-package> generate little stubs like export LD_LIBRARY_PATH=/usr/lib/network-2.0/ghc-6.6/:$LD_LIBRARY_PATH in /usr/lib/ghc-6.6/package-scripts/. Every deployed wrapper could then have the form #!/bin/sh source /usr/lib/ghc-6.6/package-scripts/* $0.real-binary "$*" -- Fruhwirth Clemens - http://clemens.endorphin.org _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
