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

[skaller]

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 ;) 

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.

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

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 ;(

> 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.

Which has problems of its own -- and is strongly discouraged
by systems like Debian. Don't even think about it, rpath is evil.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net