Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and OpenSSL

[Duncan Coutts]

On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:

> I think the main problem here is that I'm using Windows, so there is no way 
> to dynamically link with the runtime libraries - the GHC implementations 
> available for Windows only produce statically linked executables.
> 
> Perhaps Windows support was just an afterthought from the main development 
> of GHC on Unix, but I think it's quite a serious nusiance that the GHC 
> runtime incorporates LGPL'd components in the light of the absence of the 
> facility to dynamically link with it on this platform.

I think part of the issue is that static linking is very convenient and
dynamic linking in this case would lead to some tricky administrative
problems.

Suppose for a moment that GHC did dynamically link gmp.dll, or indeed
HSbase.dll. Where exactly would these files go?

Currently I can cd to a random directory and compile something:
ghc --make Foo.hs -o Foo.exe

and then expect that Foo.exe to actually work.

Now as far as I understand Windows dll technology this requires either
that:
     1. gmp.dll be copied into the directory with Foo.exe
     2. gmp.dll exist in the windows or system directories
     3. gmp.dll exist somewhere on the windows search %PATH%

None of these are attractive or scalable solutions.

1 is ugly and doesn't scale if we dynamically link all GHC packages.
2 and 3 are remarkably fragile. See dll hell. For example they do not
allow multiple versions of ghc to co-exist happily.

Windows is very well set up for distributing isolated applications but I
can't see how to do it for libraries. COM works by a runtime loading
mechanism and a single entry point per dll and registering the location
in the win32 registry.

MSVC now supports a delayed loading mechanism that might work. It allows
the loading of the dll to be delayed until the first call into it is
made. So it might be possible to delay load all the dlls and then on
startup explicitly load them (assuming you do have some mechanism for
locating them).

On Unix this isn't a problem because it's possible to embed the dynamic
library search path into an executable (and indeed into a dynamic
library) using the -rpath linker directive.

Duncan