views:

514

answers:

1

Here is my situation:

I have a C project linking with many libraries (I haven't written this application), and it is shipped also with MSVCR71.dll and MSVCP71.dll. Even without those DLLs, the program has run fine on my system, which has MS VS2005 installed (indeed uses MSVCR80.dll and MSVCP80.dll).

I've linked this application with other libraries, compiled on my system. Now, after having linked with those libraries, the application don't start because it cannot load MSVCR80.dll and MSVCP80.dll... very strange, I say.

Loader presents to me the error R6034, which should be solved building applications using the manifest file.

What's wrong with this application?


Confirm that the problem was introduced by the libraries introduced. May I compile those libraries without manifest or statically?

Still curious why application without linking new libraries don't find MS runtime DLLs...

+1  A: 

MSVCP71.dll is a dll used by Visual Studio 2002. MSVCR80.dll is for Visual Studio 2005. So, when you recompiled this app with VS2005 you got new dll dependencies. You cannot solve it with manifests - you should recompile it in Visual Studio 2002 or just put these new dll's into the same folder where you app is located.

Edited: And yes, you can just link your application with static CRT libraries to avoid external dependencies on these dll's. But it may be not possible if one of dll's or libraries that you link with uses dynamic CRT - you should recompile them also with static CRT then.

Oleg
It was exactly what I've done. The application is unable to load MSVCR80.dll when I linked new libraries (compiled with VS2005 on the same system). The error R6034 is displayed BECAUSE I've copied those DLL on the working directory of the application.Any ideas?
Luca
OK, now I got it.MSDN shows very descriptive text about this error:"An application has made an attempt to load the C runtime library without using a manifest. This is an unsupported way to load Visual C++ DLLs. You need to modify your application to build with a manifest. For more information, see the "Visual C++ Libraries as Shared Side-by-Side Assemblies" topic in the product documentation."So, just enable default manifest creation in project settings and everything will be working fine. You don't need special manifest - just some manifest.
Oleg
Actually the application uses manifest (by using /MANIFEST /MANIFESTFILE:...\asdasd.exe.intermediate.manifest"). Or am I wrong? What about other DLLs (it links with pthreadVC2.lib glut32.lib glew32.lib Cg.lib CgGL.lib Half.lib Iex.lib IlmImf.lib IlmThread.lib Imath.lib zdll.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib...)
Luca
Strange.Do you have warnings about manifest when you compile project? Also you can open your compiled exe and check is there your manifest integrated inside. There are tools available for that (AFAIR visual studio can do it if you just drop exe there).You may connect debugger and check when this error is shown - is it in your main process initialization or when one of other dll's initializes.
Oleg
No warnings, and I confirm manifest is embedded to executable. Compiling in Release runs correctly (probably I put non debug version of those dlls). Still wondering why DLLs on system are not loaded anymore, but I have to copy MS*.dll files on working directory. +1 for the support! :)
Luca