Locating shared libraries
clemens at endorphin.org
Wed Jun 13 09:00:04 EDT 2007
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).
> > 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
in /usr/lib/ghc-6.6/package-scripts/. Every deployed wrapper could
then have the form
Fruhwirth Clemens - http://clemens.endorphin.org
More information about the Glasgow-haskell-users