I'm trying to make my C++ into a .lib file to use with my projects.
I have the files Log.h and Log.cpp.
I went into my project properties in Visual Studio and changed the configuration type from .exe to .lib. I set the build mode to Release and built my class into a file called Log.lib.
In a new C++ project, I'm trying to include that .lib file I made along with the Log.h file. All was successful, it recognised my functions, but when I try to run my exe program with my included Log.h, I get the following errors:
mismatch detected for '_ITERATOR_DEBUG_LEVEL':
value '2' doesn't match value '0' in main.obj
By referencing this stackoverflow post, I discovered that building and running my new project in Release mode (the same as the .lib mode) removes the errors and I can successfully run my program and use the Log.h.
How can I compile my Log.h lib to be compatible with both Debug and Release?
You have a mismatch in the version of the C runtime library that your projects are linking to. One of the projects is linking to the debug version of the CRT, while the other one is linking to the release version of the CRT. That mixed configuration is not supported, and it is resulting in the error message. The standard library template classes are actually different in debug and release builds.
You need to check the settings for all of your projects (everything that generates either an EXE or a LIB file as output), and ensure that they are all using the same version of the CRT. This is the /MT or /MD switches passed to the compiler.
It is not possible to build your lib to be compatible to Debug and Release C runtime library (CRT).
See also here.
But it is possible to change the version of the CRT in your exe project: If both the debug and release configuration use the same version of the CRT (e.g. Multi-threaded DLL (/MD)) you can build your lib in release configuration and use it in release and debug configuration of your exe program (which will result in poorer debug support).
To change the runtime library in Visual Studio, open the Project Properties and go to "C/C++" - "Code Generation" - "Runtime library" (this depends on the version of Visual Studio you use, but should at least be valid for VS2010-2015).
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 had a C/C++ Visual Studio 2013 Community Edition project that was defined to generate a DLL, and I'm having a lot of misery with "undefined symbols" which I wanted to use in another project, so I decided to see what it would give if I changed the project settings so that it would generate a static library instead.
So in the Properties window of the project I went to
Configuration Properties > General > Project Defaults > Configuration Type
and set the Configuration Type to Static Library
The target extension is .lib.
When I do a rebuild I still get a fresh dll file in my Release folder, as well as a lib, and the DLL file is much bigger than the lib file. This makes the lib file look like an "export lib" file and it looks like nothing has changed.
This still happens if I stop and restart Visual Studio.
Am I missing something or does this look like a bug to you?
In Configuration Properties - C/C++ - Runtime Library change setting to Multi-threaded (/MT) for Release configuration and to Multi-threaded Debug (/MTd) for Debug configuration.
Also, check Configuration Properties - General - General - Target extension is set to .lib.
Check settings for all configurations (Release and Debug if you use them).
Why have you changed your project type? If you need DLL, build DLL. Post exact errors received during DLL compilation. Perhaps you missed some dllexport/dllimport declspecs.
Regarding .lib: are you sure, that DLL is generated during build? Perhaps it is the output from previous (DLL) configuration? Have you tried to compile test app using this .lib? Perhaps it is valid and compiled properly?
Another matter: have you removed all dclspecs from function signatures after project type change? When building static library, none of them are applicable.
I have created a wn32 project with Visual Studio 2008 and Visual C++ language, it uses the ws2_32.lib library and then I compiled in Release mode.
It runs very good in the same computer, but when I copy the exe file to other computer (that doesn't have installed Visual Studio), it doesn't run.
The message I see is:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
But, if I compile my application using DEV C++, it generates a bigger executable (738KB) compared with the Visual Studio 2008 executable (9.5 KB). However, the DEV C++ executable runs in the other computer.
I have add the library ws2_32.lib to the linker properties of my project, in the Additional Dependencies field.
How can I fix it to work with Visual Studio 2008?
My code is the following: http://www.stan.com.mx/yupi/udpserver.cpp
The problem is almost certainly that the other computer does not have version 9 of the C++ CRT installed.
The default setting for compiling against the CRT in VS2008 is to dynamically link vs. statically linking. If you want to deploy your program with a real setup project you'll need to include the CRT redistributable.
However if you want to do an XCOPY deployment follow the steps on the following page.
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Try installing the Visual C++ redistributables. If that doesn't work, use DependencyWalker to find out what DLLs are missing.
I agree with JaredPar. The application you build with VS2008 is using dynamic linking, whereas the DEV C++ is linking statically, hence the larger size and why one works and not the other.
However, if its a plain win32 application project you've got (and you don't want/need to distribute it with a setup), you may be able to get it to run on another machine without redistributing the CRT by getting VS2008 to link statically for you (if its just the standard lib you're missing). I don't have a copy of VS2008 to hand, so I'll describe how to do it in VS2005 and hopefully it'll translate across.
Bring up configuration properties for the project (right click the project name, then select "properties" from the menu)
Expand "Configuration Properties", then "C/C++", then click "Code Generation"
Under the "Runtime Library" item, for your particular configuration select the non-DLL version of the library i.e. for debug builds you want "Multi-threaded Debug (/MTd) and for release builds you want "Multi-threaded (/MT)"
Try and see if that works. You'll obviously get a much bigger final binary now the library is statically linked.
You may be missing an external dependency required by your program. Check the project settings to see if you are linking against MFC dynamically for example. You can also run Depends utility to check for missing dependencies.