Locating shared libraries

[Bryan O'Sullivan]

Clemens Fruhwirth wrote:

> At the moment, my second patch teaches Cabal how to build shared
> libraries. Basically, this is:
>   * add -fPIC to the compiler invocation (and -optc-fPIC for c-sources),
>   * invoke "ld -shared -Bsymbolic -o foo.so obj1.o obj2.o ...". 
> 
> ATM, ld is not invoked with the inter-library dependencies for the
> shared library being built. This is not problematic as the final
> executable will include all dependencies due to the ghc package
> dependency tracking. But DT_NEEDED on ELF influences the sequence in
> which shared library initializers are run. I have not yet investigated
> if this leads to any problems.
> 
> 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.

> How do we translate these solutions to GHC? The first question is
> whether we expect 
> 
> ghc -dynamic -package uninstalled-package -o Hello Hello.o
> ./Hello
> 
> to work or whether we require manual intervention in these cases.

Manual intervention is definitely the right thing.  I could perhaps see 
Cabal's build command having a --in-place option that spits out a little 
shell script that augments LD_LIBRARY_PATH appropriately, but anything 
more will lead to trouble.

> 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.

	<b