On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote: > On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
> 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? > 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. Nor is static linkage ;) FWIW: Windows has obsoleted your solutions above. It now uses a thing called 'assemblies'. This involves shipping all the dependent dll's with an application or library, and embedding a 'manifest' in each executable object. On installation, the dll's are copied into a cache if necessary, and the dynamic loader knows how to find them there. Versions of a library are kept distinct. In particular note this applies to the C library (MSVCR80.DLL) which is not considered a system library on XP anymore, XP64 in particular. Exactly how MinGW version of gcc will cope with all this I do not know. I personally couldn't figure out how to make it all work ;( > 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. Which has problems of its own -- and is strongly discouraged by systems like Debian. Don't even think about it, rpath is evil. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
