At Tue, 12 Jun 2007 08:28:08 -0700,
Bryan O'Sullivan
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