On Tue, 2006-08-01 at 17:05 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
So where do I put the Gtk+ .dlls? At the moment I seem to have no choice but to put them on the %PATH%. And thus the breakage ensues. Old versions of Gtk+ that people have on their systems can interfere. Lots of naughty apps seem to install libz.dll into the windows system directory. The list seems endless. Each of these dll problems results in the Haskell GUI apps that users compile failing to start due to missing or mismatched dll imports.
The "solution" to this problem is to use COM - COM assigns a unique identifier to an API, and you're only supposed to replace a DLL if you implement all the interfaces that the old DLL implemented, plus possibly some new ones.
I've been talking to John Skaller about assemblies which do seem like a potentially sane solution to this problem As John pointed out in WinXP and above there is this assemblies mechanism that works not just for .NET but for native stuff too. If you look in your Windows/SxS/ directory you'll find a number of shared "side by side" assemblies. An assembly consists of a set of dlls with one dll containing an embedded xml manifest file that describes the name and version and member files of the assembly. Then any other .exe on the system is allowed to have an associated or embedded manifest that specifies dependent assemblies. The runtime linker then looks for these assemblies in the apps' private dir (ie subdirectories of the dir containing the .exe) or in the shared Windows/SxS assembly collection. The tools to embed manifests are not particularly complex. There is a mt.exe that embeds a manifest in a .exe or .dll after it's already been linked, or the resource compiled rc.exe can embed it during linking. I've not yet found out if mt.exe works on gcc-compiled .dll or .exe files. You can read about mt.exe and side by side assemblies here: http://windowssdk.msdn.microsoft.com/en-us/library/ms716972.aspx So, supposing this works, how might it apply to ghc? We could add an assemblies section to the .cabal/package.conf info, much like the OSX frameworks thing. However it'd need ghc to call some tool to embed an xml manifest specifying these dependencies in the generated .exe. It's not clear if such a tool is freely available. As for Gtk2Hs on Windows, I'd need to turn Gtk+ into an side by side assembly by producing and embedding a manifest in a representative gtk .dll and then specify this as a framework dependency in the cabal/package.conf file. Not trivial. Duncan