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

[Duncan Coutts]

On Tue, 2006-08-01 at 17:05 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:

> > 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.
> 
> The "solution" to this problem is to use COM - COM assigns a unique identifier 
> to an API, and you're only supposed to replace a DLL if you implement all the 
> interfaces that the old DLL implemented, plus possibly some new ones.

I've been talking to John Skaller about assemblies which do seem like a
potentially sane solution to this problem

As John pointed out in WinXP and above there is this assemblies
mechanism that works not just for .NET but for native stuff too. If you
look in your Windows/SxS/ directory you'll find a number of shared "side
by side" assemblies. An assembly consists of a set of dlls with one dll
containing an embedded xml manifest file that describes the name and
version and member files of the assembly.

Then any other .exe on the system is allowed to have an associated or
embedded manifest that specifies dependent assemblies. The runtime
linker then looks for these assemblies in the apps' private dir (ie
subdirectories of the dir containing the .exe) or in the shared
Windows/SxS assembly collection.

The tools to embed manifests are not particularly complex. There is a
mt.exe that embeds a manifest in a .exe or .dll after it's already been
linked, or the resource compiled rc.exe can embed it during linking.

I've not yet found out if mt.exe works on gcc-compiled .dll or .exe
files.

You can read about mt.exe and side by side assemblies here:
http://windowssdk.msdn.microsoft.com/en-us/library/ms716972.aspx


So, supposing this works, how might it apply to ghc? We could add an
assemblies section to the .cabal/package.conf info, much like the OSX
frameworks thing. However it'd need ghc to call some tool to embed an
xml manifest specifying these dependencies in the generated .exe. It's
not clear if such a tool is freely available.

As for Gtk2Hs on Windows, I'd need to turn Gtk+ into an side by side
assembly by producing and embedding a manifest in a representative
gtk .dll and then specify this as a framework dependency in the
cabal/package.conf file.

Not trivial.

Duncan