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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
