[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: dynamic x static (win32)
- From: Antonio Scuri <scuri@...>
- Date: Tue, 07 Dec 2004 22:54:38 -0200
Just for the records, in Tecgraf we build static libraries for several
compilers, including Visual C++ 6 and Visual C++ 7, but all the DLLs were
build using Visual C++ 6.
As correctly stated by others here and by the ZLIB1 people, is highly
recommended that your application and all other libraries use the same run
time library. This is a frequently question (and a mistake) done by our
users when they start using DLLs. So since we are distributing libraries
for developers they should have the MSVCRT*.DLL and the import library.
MSVCR71.DLL is not available by default and you will have to build the
import library for the compiler you use. Then it is more complicated to
explain that Visual Studio .NET contains Visual C++ 7.0 that uses
MSVCRT70.DLL and Visual Studio .NET 2003 contains Visual C++ 7.1 that uses
MSVCRT71.DLL. It is a mess!!! But for MSVCRT.DLL everyone has its import
If you distribute an application pick up one, make sure every library
use the same RTL, and distribute it together.
If you distribute libraries, as we do, I suggest you to use the simpler
solution that is to use VC6 just to build the release dll.
I hope that Microsoft will improve this in the future...
At 22:13 7/12/2004, Danilo Tuler wrote:
Thanks for the link.
I was wondering about zlib1.dll today (luazip uses it).
I don't agree 100% with his arguments not to use MSVCR71.DLL. He says that
"although it is available for free download and distribution, its presence
is scarce on today's Win32 installations".
But as microsoft says in
"MSVCR71.DLL is no longer considered a system file", as such, it must be
distributed with the application.
What do you think about this? Should I go back to Visual C++ 6.0 and
compile all kepler libraries with MSVCRT.DLL?
David Burgess said:
> On msvcr71.dll see
> This explains their reasons for using msvccrt.dll with VC7.
> On Tue, 7 Dec 2004 11:04:08 -0300, Danilo Tuler <firstname.lastname@example.org> wrote:
>> > You can do this if the module that is dynamically linked to
>> > lua.dll uses a dynamically linked runtime, and your app (with the
statically linked Lua) does the same thing. In this case
>> > both parties would be running on the same (shared) runtime
>> > dll and everything should be alright.
>> Yes, this is the case, both are linked to msvcr71.dll.
>> I thought everything should be alright too, but I'm experiencing
>> Whatever... I'll go with all-dynamic.