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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
