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

[Milan Gornik]

----- Original Message ----- 
From: "Roumen Petrov" <address@hidden>
To: "Milan Gornik" <address@hidden>
Cc: "Bruno Haible" <address@hidden>; <address@hidden>
Sent: Tuesday, January 15, 2008 10:37 PM
Subject: Re: [bug-gnu-libiconv] libiconv 1.11.1 - MS VS 2005 and manifest
files


> ...
> First of all is know that an application should use binary(ABI) compatible
> shared libraries. For unknown ( may be :) ) reason builds with "Microsoft
> Visual Studio" require application to depend from a specific runtime
> library. It is know that application will crash if application and a
> dependent shared library use different specific runtime library.
> If I understand Microsoft try to resolve DLL fiasco: first try is to
> resolve issue with version name as part of library name and second try is
> manifest file where required (exact !?!?) internal library version should
> be written.
>
> But I could not imagine that "Microsoft Visual Studio" could not build
> against msvcrt.dll ( internal version 4.2 I think ) that is part of OS
> (recent versions) and shouldn't require additional installation of
> "Redistributable package".
> I think that liker flag /NODEFLIB (?) could help.
>
> To resolve MSVCR fiasco is acceptable for you to use compiler,linker and
> nmake from Windows XP DDK ?
>
>
> What is exactly you problem? Could you application start without manifest
> file, if it is build against msvcr80.dll from vs service pack 1 but on
> host system is installed old msvcr80.dll ?
>
>
> Roumen

Hello Roumen,

I believe they dropped the old MSVCRT.DLL in Visual Studio 2005 as there are 
big differences between old and new CRT. Basic difference is that CRT now 
has "safe" routines, counterparts to number of standard C functions, but 
working in safe manner. This safety means that most of functions now do 
parameter validity checking, range checking etc. There are other differences 
which make this new CRT incompatible with the old. I am not 100% sure, but I 
haven't seen an option to build code using old CRT with Visual Studio 2005. 
Linker flag /NODEFAULTLIB, as I believe, is a way to turn off linker check 
on dependencies to specific libraries, but it couldn't be used to use one 
CRT instead of another.

However, it is still possible to just use old Visual Studio binaries with 
new Visual Studio applications. For example, I could build libiconv in VS 98 
and use that dll with application written for VS 2005. That dll would depend 
on old CRT (MSVCRT.DLL). The reason why I haven't done this is because one 
of the project requirements was to avoid dependencies to old system 
libraries whenever possible.

I'll try to describe initial problem once more: 1. built libiconv (1.11.1) 
with Visual Studio 2005, 2. built application in VS 2005 that uses libiconv, 
3. installed libiconv binaries on target machine, 4. installed application 
binaries on target machine. The problem was that when application is started 
it would use libiconv, but as libiconv doesn't has manifest with it, OS 
doesn't know which CRT to use. One resolution is to copy manifest along with 
the libiconv, and what I proposed was to integrate manifest file with 
libiconv binaries. So the problem is basically solved. I contacted newsgroup 
because I wanted confirmation on if this is correct thing to do, and also 
wanted to suggest that these changes could be added to libiconv 1.11.1. 
However, as Bruno explained, this is not possible as it could lead to GPL 
license issues.

The same story could basically go for any library built with VS 2005. So, I 
hope several last postings could help out guys that are having these same 
worries.

Regards,
Milan Gornik