On 06 December 2004 14:39, John Goerzen wrote:

On 2004-12-06, Keith Wansbrough 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.

BTW, is this a problem even if no -O options are given when building a library?

Certainly it's possible to get a more stable library ABI by not compiling with -O. The question is, do you want to? You certainly don't want to do this for the Prelude and other essential libraries. For example, GHC wouldn't be able to see the definition of 'instance Num Int', and hence (x + 1 :: Int) would be compiled as (+) dNumInt x (I# 1) instead of (after inlining (+) and dNumInt): case x of I# x# -> I# (x# +# 1#) which can then be further optimised: the compiler can see that it is strict in x, so might be able to unbox x, and so on. This is pretty essential to get any kind of reasonable performance, but it might be less important for higher-level libraries, as long as you don't have any important monads that need to be inlined, for example. Dynamic linking is (almost) a separate issue. GHC 6.4 will have some support for dynamic linking in the native code generator thanks to Wolfgang Thaller, but it needs someone to push it the final mile on x86/Linux and Windows. Dynamically linked libraries will work (albeit slightly slower than statically linked ones), but you still have the versioning issue. Since libraries are getting really big nowadays (eg. wxHaskell) making dynamic linking work even without worrying about versioning seems like it would be worthwhile. Cheers, Simon