Re: [bug-gnu-libiconv] libiconv 1.11.1 - MS VS 2005 and manifest files

[Bruno Haible]

Hello Milan,

Milan Gornik wrote:
> I am using libiconv 1.11.1 with Microsoft Visual Studio 2005 and I have 
> encountered one problem. Iconv builds fine and works fine until binaries are 
> distributed to machine without development environment. On such machine, 
> binary built to use libiconv will fail to execute, as it can't bind with CRT 
> runtime (MSVCR80.dll). Application will stop with dialogue explaining that 
> MSVCR80.dll could not be found.

The same problem is mentioned in libiconv-1.11.1/README.woe32, for MSVC 7.0
and the msvcr70.dll library.

A possible fix is to get back to MSVC 6.0.

> This happens because OS seeks for 
> executable's manifest file to determine which CRT to use with the 
> executable. In this case, no manifest files are available. When Iconv 
> library is built, manifest files are generated for every output file (EXE 
> and DLL), but these files are left behind (in source folders). They are not 
> installed to output folder. As makefiles are designed for Visual Studio 98 
> (v6), there are no special options in makefiles regarding manifest files. 
> Linker generates these files by default.
> 
> I believe that best option would be to integrate manifests with their 
> appropriate output files (EXE files and DLL files). This makes minimal 
> impact on how Iconv is built (no additional files, installation phase is not 
> affected, build phase is extended with manifest file integration). The 
> result will be that every DLL and EXE will contain embedded manifest (and 
> will run correctly on machine without development environment). Small 
> modification to makefiles is needed to achieve this. I followed 
> recommendations in MSDN to do this. I attached diff files to this message.

This looks like a hack to me. You build a library for use with MSVCR80.DLL
and then relabel it to work with MSVCRT.DLL? There is no guarantee that this
will work. Surely MSVCR80.DLL contains more symbols than the older DLL.
What happens if one of the symbols needed by iconv.dll is present in
MSVCR80.DLL but not in MSVCRT.DLL? The application that needs iconv will
certainly crash. Since we don't have a 100% test coverage of libiconv,
you cannot know about this case before it actually happens on the deployment
machine.

IMO the right solution is to tell the *compiler* and the *linker* to generate
a DLL that needs only MSVCRT.DLL. If Microsoft's tools cannot do that, then
throw them away and use mingw. mingw can generate DLLs that need only
MSVCRT.DLL.

Bruno