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?
Related
The process is extremely non obvious and error prone so I think a place where a proper procedure is described is required.
I will answer my own question below, but it is more or less a hack and slash solution as Visual Studio is mostly Terra Incognita for me and I just stumbled on a combination that works after a lot of trial and error, sometimes not even understanding what I am doing. If it looks horrible - sorry about that. There was simply no proper guide for me to use.
Steps:
Download GRPC and Protobuf3 from their respective github repositories.
It is better to use GRPC from repository than from zip package because this way you will be able to populate "third_party" folder via git.
Download CMake/CMake-gui and feed protobuf\cmake folder to it. This will generate your visual stuido projects
Compile All_Build.vcxproj as is in release mode. This will generate protoc.exe file which you must store somewhere.
Here comes the trickery:
By default, Release protobuf/grpc projects are compiled as /MT.
Chances are - qtcreator is compiling your projects as /MD.
If you try to use the library generated by MSVC as is - you will get a library format conflict.
So first step is to edit libprotobuf subproject:
C/C++->Code Generation->Runtime Library to Multi-threaded DLL (/MD)
Next problem: default project will generate a .lib file, that even with /MD I have been unable to succesfully attach.
If anyone knows how to avoid a lot of "undefined reference" errors while trying to use it, feel free to comment below.
// these are only necessary if you can't link statically as I do
Configuration Properties->General->Target extension : .dll
Configuration Properties->General->Configuration Type : Dynamic Library
We also have to add a bunch of defines:
Configuration Properties->C/C++->Preprocessor : add PROTOBUF_USE_DLLS;LIBPROTOBUF_EXPORTS
Now you can compile protobuf. Do this and store libprotobuf.lib and libprotobuf.dll somewhere
Onwards to grpc.
Open grpc.sln
As I am not using MSVC for my work routinely these later steps were non-obvious.
You will need Nuget installed in Visual Studio before anything else.
Nuget will, on compilation, pull a bunch of dependencies into your grpc\vsprojects\packages folder.You will need .dll's from there later if you plan to deploy your app.
Once it's installed go and switch /MT /MTd to /MD /MDd depending on the mode you plan to use, the same as for protobuf.
/MD corresponds to Release build (for me) while /MDd is for Debug
Also, you need to remove "z" and "borinssl" subprojects as they are broken on windows and won't let you compile properly.
Compile the project. It will produce grpc.lib grpc_unsecure.lib grpc++.lib grpc++_unsecure.lib which you will need to store somewhere accessible to qtcreator while it builds your project (same with libprotobuf.lib and libprotobuf.dll)
Open grpc_protoc_plugins.sln
Add a folder that has libprotobuf.lib to Library Directories in project configuration.
Compile grpc_cpp_plugin. It will produce grpc_cpp_plugin.exe which you need to store with protoc.exe
If you plan to deploy your app you will need to copy a bunch of dependencies nuget collected for you from packages folders:
libeay32.dll
ssleay32.dll
zlib.dll
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 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.
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)
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.