Locating shared libraries

[Clemens Fruhwirth]

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