bug-gnu-libiconv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Milan Gornik
Subject: Re: [bug-gnu-libiconv] libiconv 1.11.1 - MS VS 2005 and manifest files
Date: Wed, 16 Jan 2008 16:11:40 +0100


----- 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]