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

[Brian Hulley]

Duncan Coutts wrote:
> 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?

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.

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

I know - I like this too. Also static linking seems to give more opportunity 
for optimization. If it wasn't for the LGPL restrictions there would be no 
problem (except that GMP might not have been written :-( (but then some nice 
person at GHC would probably have written or found a BSD3 lib instead... 
;-) ))

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

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.

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.

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

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

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.

Also, the only things that need to be in DLLs are the LGPL libs - everything 
else could be statically linked.

(Am I correct that the only LGPL component of GHC is GMP?)

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

It's also possible to call the Platform SDK function LoadLibrary with an 
explicit path to a DLL, but there are some restrictions on the use of 
LoadLibrary so I wouldn't recommend this - it's getting too complicated ;-)

Regards, Brian.
-- 
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com