Third-party C libraries policy?

[Claus Reinke]

>> Currently, glut32.dll is not bundled with the Windows installer,
>> though it probably should be. I vaguely remember that it is not
>> part of the base XP install (though I have glut32.dll in
>> WINDOWS\system32 for some reason).

possibly installed there by an earlier ghc installer?

>> The question is, where should
>> we put it? Touching WINDOWS\system32 (and installing a DLL
>> system-wide in general) is not very good behaviour (the main
>> cause of the "DLL Hell"); if we use $GHC_DIR, it'll work only
>> with GHCi, but not with the standalone executables.
>
> Right, it doesn't come with XP by default. I guess it comes with most
> graphics cards's drivers.
>
> Does the existing ghc installer install glut32.dll?

Every time it didn't, that lead to bug reports (and usually updated installers).

Though it would be nice not to put it into system dirs. How about
cabal's installed programs bin dir? Or have a cabal/dlls dir, and add
that to the end of PATH?

As a very last resort, you could bundle glut32.dll, but not install it
(put it in a haskell-platform/dlls directory and advise users to do their
preferred thing to make it accessible). That wouldn't work out of
the box, but at least the box would come with all parts, and users
would be in control, if they prefer using another version of glut32.dll,
such as freeglut's).

In future, it would really be good to have a general solution for all
cabal-installed software using non-system .dlls.

>> In general, what is the policy on third-party C libraries such as
>> GLUT and OpenAL? Should we bundle them with the Haskell Platform
>> installer or let the user search for them on her own?
>
> I'm not sure yet. Ideally we bundle them but dlls are a particular
> problem for Windows because currently there's nowhere sensible to put
> them where they will be found by programs that users compile themselves.
> Supporting isolated assemblies might make it better (though they can
> only be installed by admin).

googling for "msdn load dll" gives

    what is a dll?
    http://support.microsoft.com/kb/815065

with useful references, but there seem to be too many options and
variations to make sense of easily (one would think that the .exe.manifest
files would be a sensible place to point to local .dlls, but that is just a
guess).

Another option might be to establish a convention for local dlls
for cabal/ghc-built executables (such as: always look for .dlls in
<cabal>/<package>/dll, for the <package> that depends on .dll),
and to instrument the generated executables accordingly - see
"Alternate Search Order" here:

    Dynamic-Link Library Search Order
    http://msdn.microsoft.com/en-us/library/ms682586.aspx

That way, you'd at least have control over what happens and
could make choices matching cabal's package handling.

It appears that (in the versions of windows discussed there)
putting the .dll next to the application would work, which I've
used in the past, but it wouldn't make sense for cabal to put
a copy of glut32.dll next to every executable using glut!-)

Claus