It's strange, if I build my program in debug mode, I have no errors, but if I build my program in released mode, I get an error saying that Msvcr90d.dll is not found.
Msvcr90d.dll is a debug library, I'm not sure why it's coming up when I load it for release =/
msvcr90d.dll is a debug version of C/C++ library. It looks like you have a dependency somewhere on a debug target. Check that all the projects in release target use the release version of C runtime, and not the debug. Also, check other 3rd party libraries (DLLs) that you might use, so they not depend on msvcr90d.dll
You can use dependency walker tool to check the dependencies of your binaries, so you can identify the project in your solution that still depends on debug version of C library.
If you are getting the warning LNK 4098 during build, please see this
http://msdn.microsoft.com/en-us/library/6wtdswk0(VS.71).aspx
And follow the recommendations.
Also, make sure that you chose the correct C/C++ runtime under the Code Generation tab (Multi-threaded DLL -- not Multithreaded Debug DLL)
Related
I am trying to use the DirectXTex library for my project. I cloned it from GitHub and built it using the Visual Studio 2019 solution for desktop, with the exact same code generation settings as in my own project. It works fine for debug configurations, but when I build on release, an error message similar to this occurs:
_ITERATOR_DEBUG_LEVEL: Value 2 of (some DirectXTex .obj) is conflicting with value 0 of (my own .obj)
which goes along with this message:
Runtime library: MTd_StaticDebug of (some DirectXTex .obj) is conflicting with MT_StaticRelease of (my own .obj)
This is strange, because I set the runtime library of both projects to Multithreaded (/MT) for release and Multithreaded-Debug (/MTd) for debug. I have done some research and found this article that covers this exact problem, but none of those solutions work for me. I tried the following:
See if _DEBUG preprocessor is defined in release mode build of DirectXTex for some reason (it is not)
Try to set both project settings to Multithreaded-DLL
Checked if all code generation settings are really the same (debug and release)
Checked if I use the correct library build for debug and release
Made a clean new build in case my .obj files are older versions
None of these worked. But it compiles and works fine for release if I set the runtime library of my own project to Multithreaded-Debug for release mode aswell. This is obviously not an ideal solution.
What I also don't understand is that the DirectXTex library seems to build the release configuration of DirectXTex with MT_StaticDebug (at least the error message indicates that), although I explicitly set its runtime library to Multithreaded (/MT) for release. How can I fix this?
The DirectXTex_Desktop_2019.vcxproj in the GitHub repo is set to use /MDd for Debug and /MD for Release. Using the DLL-based Visual C++ runtime is recommended for numerous reasons over static CRT linking.
With that said, if you are using static linking, then you should verify that in each Platform/Configuration combination that they are set correctly as it seems like you don't have /MTd set in all of Debug configurations cases. For example, do you have both x86 and x64 platforms in your project?
All of a sudden, my program got link errors like below:
libcpmtd.lib(xlock.obj) : error LNK2038: 'RuntimeLibrary' unmatched.The value 'MTd_StaticDebug' is different from that of [project x], which is: 'MDd_DynamicDebug'
Since this error suddenly appeared on multiple computers, I believe this was not caused by unintended modification of any file.
Version: Visual Studio 2013
Question-1:
Could you give any hint about the reason of this error and how to solve it?
What I did:
I remove the libcpmtd.lib from the import library list of project setting, then the build error disappeared and everything was OK.
But, I am not sure what libcpmtd.lib is for?
Google told me there is CRT inside, but what are the content specifically?
Perhaps this library was added and then not relevant from some point of time.
Question-2:
what is in side libcpmtd.lib? I want to figure out what I might have lost after I removed the lib.
These are the C++ standard runtime libraries. With Visual C++, you have 2 options, which give you 4 permutations of the library it links to.
Debug v.s. Release
As it suggests, do you want the C++ runtime lib that has additional error checking?
Static v.s. Dynamic
If you happen to be compiling only a simple exe, then linking to the library statically should be fine. If however you have a large project consisting of multiple DLL's, then it makes sense to load the CRT dynamically (so it can be shared between the DLL's, rather than being duplicated into each one).
So what you have is a mis-configured build. You'll need to check the C/C++ Runtime Library settings for each library, DLL, and exe within your project (which you can find in your project settings, under C/C++ -> Code Generation).
You will need to make sure that each one links to the same runtime library (i.e. Debug DLL for all debug settings, Release DLL for all release settings).
If that doesn't fix it, then there are two other possible causes:
You have started linking to a 3rd party library, and that's the cause of the CRT mis-match. Most libs ship debug and release builds for this reason, so hopefully you'll just need to update the libs you are linking to.
You are inadvertently pulling in a Debug lib into a release build (or a release build lib, into a debug exe). For this you will need to check all of the additional library directories, and/or check to make sure all of the debug & release output directories are correct (i.e. you aren't accidentally compiling a debug lib into a release build folder).
I am using a VS2015 to create DLLs which will be used in a project (which will be run on another PC).
I have build the DLLs in Release version on my PC but when I start the project on another PC, I get following errors:
VCRUNTIME140D.dll is missing
MSVCP140D.dll is missing
MSVCP140D.dll is missing
What steps should I take while creating these DLLs so that these debug runtime DLLs won't be required to the run the project on any PC.
In spite of it being built in release mode, if you require "...D.dll", then there are debug builds in the mix.
This could be the result of the third party dll you have or there are DEBUG or _DEBUG defines floating around.
Most likely is that the build (of the dll or the host exe) is explicitly set to use the debug version of the runtime (/MDd). Change this in the project settings to not use the debug version of the runtime (/MD).
Open the project's Property Pages dialog box.
Expand the C/C++ folder.
Select the Code Generation property page.
Modify the Runtime Library property.
To assist in the diagnosis of which binary is responsible for the debug dependency, you can use Dependency Walker to track down the offender. It will give you a list (as a tree) of the dependencies of each file.
In general, for missing the C++ runtimes (release version) on a target machine, you should install the C++ redistributable. As of this writing, VS 2015 redistributable is available here.
In C/C++ -> Code Generation -> set Runtime Library to:
Multi-threaded Debug (/MTd)
And yes, such setting is very much needed if you want to debug a process on a remote machine. So, don't go by others saying, "test with Release build only". Obviously, you'll need Remote Tools installed.
As stated by Niall, you should use dependency walker in order to find which part of the project is causing the error, it might not be the dll in issue after all.
My bet is it's just some part of the project you forgot and built in debug mode, which of should never be used for production as debug dlls are not included in C++ redistrib installers.
I compiled the wxwidgets using build=release now i need to know when compiling my project should i go for a "Debug" or a "Release " build and does it make any effect?
Thanks
The build of the wxWidgets libraries and of your project needs to be exactly the same. So if you release build your application you must link with the release build of the libraries. If you try to link an application and a library that have been built with different parameters then you will get linker errors and no executable will be created.
Most people keep two copies of the built libraries, one to link with debug applications and one to link with release applications.
Nothig bad will happen, but debugging the whole project may be more difficult in debug build, because you will distribute product compiled in release mode and there is no effect.
I have written a DLL that uses boost extensively in its implementation. I have both release and debug version of boost libraries with me libboost_thread-vc80-mt-1_40.lib, libboost_thread-vc80-mt-gd-1_40.lib. I am using Visual studio to build my code and using auto-linking.
When i build the DLL in debug version it links itself with libboost_thread-vc80-mt-gd-1_40.lib which is expected, but when i am building my DLL in release mode it stills tries to link it with libboost_thread-vc80-mt-gd-1_40.lib instead of libboost_thread-vc80-mt-1_40.lib. I am using /MD while building in release mode.
I am not sure what i am missing in this, can someone please point me that.
Have you tried /MT instead of /MD?
Look if there is in the release configuration a Preprocessor Definitions with the word debug, this has to be deleted if it exist.