Locating shared libraries
bos at serpentine.com
Tue Jun 12 11:28:08 EDT 2007
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
> 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
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.
More information about the Glasgow-haskell-users