> Mmm... Keith is right,
> The latest version is libiconv-1.11 (from http://www.gnu.org).
The latest version we've verified to work with MinGW is libiconv-1.10;
we provide a mingwPORT, to assist users in installing that. Of course
the chances are good that libiconv-1.11 will also work OOTB. If you
try it, and find it to work, please update the existing mingwPORT, and
submit to the mingwPORT submission tracker:
However, Tor Lillqvist also makes a valid point:
> ... the situation with libiconv is
> "interesting" because it used to be that the official (sanctioned by
> the author/maintainer) way to build it on Windows was with MSVC, and
> the MSVC makefiles produced a DLL called iconv.dll. The libiconv 1.9.2
> I distribute is built with MSVC. I think this has changed now, and
> autofoo/libtool/gcc are to be used also on Windows. However, without
> extra hacks this then will produce DLLs that has a different name
> (libiconv-2.dll, I think).
That is what I have, from my mingwPORT build of libiconv-1.10.
> As the API or ABI hasn't changed incompatibly as far as I know, it
> would be a bit silly for me to start distributing a newer libiconv
> package with a differently named DLL and require all depending
> packages to also be rebuilt.
I couldn't agree more. I'm a firm believer in the `if it ain't broke,
don't fix it' principle. In this case, since libiconv-1.9.2 perfectly
meets requirements, why jeopardise that by chasing new releases just
for the sake of having the most recent -- especially if it makes a
bucket load of extra work for you.