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

[Duncan Coutts]

On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:

> > Suppose for a moment that GHC did dynamically link gmp.dll, or indeed
> > HSbase.dll. Where exactly would these files go?
> 
> I'd install them in the same directory as ghc.exe because this directory has 
> to be on the %PATH% for the command ghc to work so Windows would find these 
> DLLs the same way.

As you say, it doesn't work for more than one version of GHC.

And it doesn't work when names clash. If there is some lingering old
version of gmp.dll in the windows system directory or in any other
directory on the %PATH% (earlier than ghc's bin dir) then that dll gets
picked up instead and everything breaks.

> For developing apps, it would surely be fine if the DLLs were just stored in 
> the ghc directory ie c:\ghc\ghc-6.4.2\bin then when you come to distribute 
> your app, you'd simply just copy all the dlls the app needs as well as the 
> exe into the installation directory of the app. When the app runs, Windows 
> will first look in the app's directory and therefore find the correct set of 
> DLLs.

Yes, it's fine for distributing applications but not much good for
libraries.

> It's true that multiple versions of ghc could not coexist, but this already 
> is the case at the moment: if you type "ghc" at a Windows command prompt 
> Windows searches the one and only PATH variable to locate it so you can't 
> have more than one version in any case, unless you create multiple user 
> accounts and modify the user's PATH variables to point to the various 
> versions of ghc.

I use several versions of GHC at once on windows and switch between them
in a console window just by doing: set PATH=...

> > 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.
> 
> Shared components are a bad idea imho because it's almost certain that 
> someone elses's app would use a different version of a DLL - this is where 
> real DLL Hell comes in! (and probably why .NET abandoned DLLs and (raw) COM 
> in favour of assemblies)

They are pretty inevitable if you want to distribute Haskell libraries
rather than applications.

I'm not sure we can just say "don't do that".

> As long as the DLLs are stored in the same directory as the exe everything 
> should be ok - it's only when people try to share DLLs by putting them 
> somewhere else that versioning problems can arise.

Indeed.


This issue is the main source of problems that users have with the
Gtk2Hs packages that I build for Windows. I do not yet have any
satisfactory solution.

Gtk+ comes as a collection of .dll files. Remember that I am
distributing a Haskell library here, not an application. Users want to
use my library to compile their own applications, eg for tasks on a
university course.

So where do I put the Gtk+ .dlls? At the moment I seem to have no choice
but to put them on the %PATH%. And thus the breakage ensues. Old
versions of Gtk+ that people have on their systems can interfere. Lots
of naughty apps seem to install libz.dll into the windows system
directory. The list seems endless. Each of these dll problems results in
the Haskell GUI apps that users compile failing to start due to missing
or mismatched dll imports.

wxHaskell does the same. It installs it's wx-*.dll files into the
windows directory (which is probably even worse).

It's all sufficiently unreliable that I do not dare tell my students
that they can do their practical on their home machines because I would
get too many support requests.

I am very interested at John Skaller's suggestion about assemblies. I
will have to look into it. It certainly can't be worse than the current
situation! :-)

Duncan