Paul, thank you for testing the automated download and for reporting. Yes, I am still here, listening to the list :-)
> There is one problem - the update-links.bat script > copies some DLLs, notably libintl-2.dll to libintl.dll and > libiconv2.dll to libiconv.dll. > > ... > > I'd suggest at least removing these two copies > Here is my answer: Version 0.6.1 of the GetGnuWin32 package doesn't copy this two files anymore. Furthermore, it now first checks if a file already exist and if yes does not overwrite it. And yes, update-links.bat is optional. Originally I wanted to replace all broken links by correct ones. But I realized that Windows does not follow links when searching for a dll or an executable that is called from within a cmd.exe window. I encountered much other problems with gnuwin32. E.g. file.exe from the file-4.13 package brings its own rxspencer.dll (within file-4.13-dep.zip) that is not compatible with that one from the regex-spencer-3.8.g.3 package. As a consequence, the regex- spencer-3.8.g.3 package is now listed in the EXCLUDE.TXT file. Another, yet very big problem is that each package must theoretically be installed in its own directory which path name is hard-wired within the executables. This however would lead to an explosion of the amount of gnuwin32 directories. Therefore my GetGnuWin32 scripts extracts all packages in the same directory tree (that later can be copied e.g. to %ProgramFiles%\gnu- win32). This seems to lead to an accidental mixture of new and old dlls. Also, the programs don't find their configuration data in the .../etc directory. I think it would be a big improvement when the gnuwin32 binaries would have the following properties: 1. Only relative path names that refer to a %GNUWIN32% main directory are hard-wired within the executables and dlls. This main directory is, as denoted, defined by an environment variable. 2. Every binary (.exe and .dll file) has a VERSIONINFO Resource Header. If then a binary that already exists in the %GNUWIN32%\bin folder is extracted again from some new downloaded package, one can check the version before overwriting the already existing file. Of course the file version could also be appended to the file name as in name-version.dll, where 'name' must not match the regular expression -[[:digit:]] while 'version' must begin with a [[:digit:]], but I think this would be a minor solution. With kind regards Mathias ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ GnuWin32-Users mailing list GnuWin32-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnuwin32-users