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

Reply via email to