Simon Marlow writes ("RE: ghc with shared libraries ?"):
> Still can't be done, I'm afraid. At least for Haskell libraries; you could
> compile parts of the RTS and libHS_cbits shared, but we haven't done that.
>
> This message has more details:
>
> http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg02765.html
I read that message and I'm afraid I'm puzzled.
Do you mean that GHC-compiled Haskell libraries don't have a stable
ABI ? I can see that that might be true, but it might also be
possible to have a souped-up dynamic linker that could fix things up
(possibly with, as you say in the message, adverse effects on the
sharedness of the library).
But if that's all that the problem is it doesn't explain why even when
exactly the same object files are put together via dynamic linking
instead of just static it doesn't work (as I infer from people's
messages - I haven't tried it).
I was under the impression that at least on sensible platforms like
Linux, the relocation and linking that is done by the dynamic linker
is very similar to that done by the compile-time linker. In fact, on
Linux you don't even need to compile your code -fpic: without it there
are simply lots more relocations in the resulting object files and
hence in the shared library, and you end up not sharing most of the
text (because the dynamic linker has to edit it when relocating it).
So without -fpic things work, but there's just a performance penalty.
You say:
> ... for example the assumption that a data object consists of a symbol
> followed by a fixed amount of data, so that certain data objects can be
> copied into the binary's data segment at runtime. GHC's object files don't
> follow these rules, so can't be made into shared objects easily.
It seems to me that this view of `data object' is simply the
definition of what ought to go into the initialised data segment of
the resulting shared object. Unix shared libraries don't have a view
about what a `data object' is.
So perhaps this can be solved by putting things in more appropriate
sections and/or making intra-segment references more explicit in some
way so that the right relocation data is put there for the dynamic
linker ?
Ian.
