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

[Duncan Coutts]

On Mon, 2006-07-31 at 05:00 +1000, skaller wrote:
> On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote:
> > On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
> 
> > 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?
> 
> > 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.
> 
> Nor is static linkage ;) 

True :-)

> FWIW: Windows has obsoleted your solutions above. 
> It now uses a thing called 'assemblies'.
> 
> This involves shipping all the dependent dll's with an application
> or library, and embedding a 'manifest' in each executable object.
> On installation, the dll's are copied into a cache if necessary,
> and the dynamic loader knows how to find them there. Versions
> of a library are kept distinct.

Sounds good.

I've been reading the MSDN documentation on assemblies for some time now
and it's not yet clear to me if assemblies can be used without also
using the .NET common language runtime.

It seems like one needs .NET installed to use assemblies and that the
global assemblies cache is specific to a version of the .NET CLR.

Does this sound right?

I was hoping that I'd be able to package Gtk+'s collection of .dlls as a
single assembly and get that into the global cache and then get ghc to
mark .exe's that use the Gtk2Hs Haskell packages as needing that Gtk+
assembly.

> In particular note this applies to the C library (MSVCR80.DLL)
> which is not considered a system library on XP anymore, 
> XP64 in particular.

That's interesting because presumably MSVCR80.DLL is not a .NET dll. I
mean it's 'unmanaged' native code, not MSIL.

> Exactly how MinGW version of gcc will cope with all this
> I do not know. I personally couldn't figure out how to make
> it all work ;(

Well there have been suggestions that GHC should use the MS C compiler
and or linker. Sadly that would not help for my Gtk+ example which
almost certainly needs gcc.

Duncan