Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X andOpenSSL
brianh at metamilk.com
Sun Jul 30 15:02:45 EDT 2006
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
>> 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
> 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
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 ;-)
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.
More information about the Glasgow-haskell-users