[Haskell-cafe] Re: Non-technical Haskell question

[Keith Wansbrough]

John Goerzen <jgoerzen at complete.org> wrote:
> On 2004-12-06, Keith Wansbrough <Keith.Wansbrough at cl.cam.ac.uk> wrote:
> > The static vs dynamic linking question has been discussed many times.
> > The summary is: GHC is a highly-optimising compiler, and the binary
> > interface _necessarily_ changes with every minor revision (even
> > patchlevel revision) of the compiler and each library.  So you can't
> 
> We already have a way to deal with that using sonames.  It's not that
> hard, and is routinely used.

I don't think sonames are enough.  For a library A, we need to record

- version of A
- version of GHC used
- version of each package on which A depends
- version of each package on which those packages depend (recursively)

and, if package management isn't being used throughout, the precise
content of each .hs file used during compilation that was not
package-controlled.

sonames only encode a single version, the version of A.  Even if we
allow that in a dynlinked scenario the dependent packages would have
their versions encoded internally (in the names of the requested
libraries), we still need to encode _two_ versions into the name.  I'm
not aware of a routinely-used way of doing this, although I am happy
to be corrected.  I guess wouldn't be hard to come up with a scheme,
though.

The point is that this wouldn't be anything like as useful as it is in
the C world.  If you upgrade package A, your old apps can't use the
new .so - they must still use the old one, until you recompile them.
And instead of storing (number of packages * number of versions of
lib) dynamic libraries, you have to store (number of packages * number
of versions of lib * number of versions of GHC) dynamic libraries.

I'll let others (Simon Marlow?) comment further...

--KW 8-)