Third-party C libraries policy?

[Duncan Coutts]

On Fri, 2009-05-01 at 11:19 +0100, Claus Reinke wrote:
> >> 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?

Using the PATH to manage windows dlls is workable but not at all nice.
We have loads of problems with it for the gtk2hs installers. We have to
check carefully that the same dlls are not already on the PATH,
otherwise things go wrong. It's pretty fragile.

For now I think we should just do whatever the existing ghc installer
does.

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

Of course, but as you've discovered it's not simple.

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

Right, .manifest files can point to dlls however (as I understand it)
only in two places: a subdir relative to the location of the .exe or the
"isolated assembly" area under some windows system folder.

In other words, it is not possible to have dlls in a subdir of ghc's
installation location and then have arbitrary .exe files compiled by the
user find those dlls using a .manifest.

It would work if we installed the dlls to the "isolated assembly" area,
because those can be referenced (by guid) in mainfest files. However
only admin can install isolated assemblies.

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

Unfortunately this only works if we're loading the dlls explicitly. It
doesn't help with a .exe that is linked against a bunch of dll files.

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

Right, not for the random hacking use case. It'd be helpful for
preparing binary distributions. Even better is using the assembly and
manifest stuff to put all the dlls into a lib subdir (or different lib
dubdirs for each dep).

Duncan