lua-users home
lua-l archive

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

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

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:
Hi David,

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;en-us;326922
"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 <> 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
strange behaviors.
>> Whatever... I'll go with all-dynamic.
>> Danilo