Changes between Version 3 and Version 4 of SharedLibraries/Management


Ignore:
Timestamp:
May 31, 2011 10:57:31 PM (4 years ago)
Author:
duncan
Comment:

add info about windows

Legend:

Unmodified
Added
Removed
Modified
  • SharedLibraries/Management

    v3 v4  
    107107== On Windows == 
    108108 
    109 ToDo: link to the MSDN page about how DLLs are found, and the details about manifests.  Manifests provide a way to do rpath-like things, I think. 
     109ToDo: link to the MSDN page about how DLLs are found, and the details about manifests. 
     110 
     111Windows has a few ways of locating DLLs. Unfortunately none are perfect. 
     112 
     1131. Find them in the same dir as the .exe 
     114 
     115  This means you have to copy all the required dlls into the dir with the .exe. That's just about OK for a `cabal install` command but clearly not ok for `ghc --make`. 
     116 
     1172. Find them on the system (Windows/System dir) 
     118   
     119  This is the old "DLL hell" approach and is clearly out. 
     120 
     1213. Stick them on the $PATH 
     122 
     123  This just about works but is very fragile. You could imagine that there was one central place where cabal installed all libs and that we tried to ensure that location is on the $PATH. This is exactly the approach that the Gtk2Hs installer on Windows takes. As that example demonsrates however this solution is very fragile: it's easy to end up with other libs getting in the way and misc other issues. 
     124 
     1254. Use local assemblies 
     126 
     127  This is the modern variation of option 1. The dynamic linker in Win XP and later has this new system of assemblies. An assembly is a bundle of one or more DLLs that live together in a dir. An .exe can have an xml manifest baked into it that specifies dependent assemblies (by GUID). Local assemblies mean that the assembly dirs are subdirs of where the .exe lives, so instead of dumping all the dll files into the same dir as the .exe, you put them in subdirs, one per assembly. This is obviously better but they do still have to be local to where the .exe lives. You can't link to assemblies that live in arbitrary locations in the file system. 
     128 
     1295. Use global assemblies 
     130 
     131  This is very nearly perfect except for one massive problem which makes it no good as a general solution. In addition to local assemblies, the dynamic linker looks for assemblies in a global location. Then the .exe xml manifest specifies the assembly GUID and it just gets looked up in the global "SxS" assembly area. This is great. The only problem is you have to be administrator to install assemblies in the global "SxS" location. There is no per-user or non-priviledged location. So while this would be ok for global ghc installs, we still have to support installing ghc and other Haskell packages for non-root users. 
     132 
    110133 
    111134== Conclusions == 
     
    115138For Linux: On linux, we should be sure to use the --enable-new-dtags switch if we use -rpath.  Otherwise we risk having paths that can't be overridden by LD_LIBRARY_PATH. 
    116139 
     140For Windows: the classic model of `ghc --make hello.hs; hello.exe` really only works with static linking. With a build model with an explicit install/deploy phase like `cabal install` or a Windows installer then we can use a mixture of global and local assemblies. One thing worth investigating is whether Windows new support for symlinks can be used to allow local assemblies to actually live in fixed locations.