fixes for Msys+Mingw

[carlo.bramix]

Hello!

>> So, if that shared library exists, the executables are linked directly with the import library and it is absolutely not required to dynamically load it.
> 
> Not a good idea.  For one we want to have close control over what DLLs
> are used and second it should be piossible to do without inconv.dll.

I understand your needs.
However, if I understood correctly the sources, everything is decided by the presence of HAVE_ICONV.
So the code should be still work as now if you configure it in the right manner.
If this macro is not declared then it will work exactly as it was previously.
If some people built GnuPG with MSVC, they won't need to add HAVE_ICONV into their project properties and afterall I do not think that they did it.
So you could see it as a fix only for Windows' posix enviroments, if you want.
In the future we may eventually force the same behaviour even with (but not limited to) Msys by adding to configure script an option like "--disable-iconv" and call AM_ICONV only if it's enabled.
I also forgot to tell you that I was not able to make it working on CYGWIN too, because that library is called cygiconv-2.dll
If I can give you my opinion, the ability to work with iconv as import library *in addition* to current LoadLibrary() method is strongly recommended.

>> 2- compilation of scd/ccid-driver.c failed because ETIMEDOUT is undefined in Windows.
>> However, LibUSB-Win32 do not set errno, but it encodes the error code directly into the return value of the functions.
> 
> Interesting.  There is a working port of libusb now?  Any pointers - I
> am very interested.  We don't support the internal CCID driver under
> Windows.  Anyway it is a bug in that port if it does not set ERRNO
> properly.

Yes, it exists by looong time at http://libusb-win32.sourceforge.net
Last time I used it, the error value was encoded into the return value of the functions because there is no way to write _errno from old MSVCRT.
I do not think that changed, however it may be possible that the handling of error codes evolved in these last years...
Perhaps error codes are also reported with Win32 API like GetLastError/SetLastError, it should be read from latest sources of LibUSB-Win32.

Sincerely,

Carlo Bramini.