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