I’m trying to port my Tachyon Wars game project to UE4. Obviously I have a lot of legacy gameplay code which needs to be linked in with Unreal Engine generated project.
I followed “Third Party” way, and now I’m facing this blocking issue:
When my app is linking with debug configuration. Microsoft Visual Studio 2013 complains a lot about mismatching Runtime libraries, I use Multithreaded Runtime Debug DLL, when UE4 and generated project seems are using Multithreaded Runtime Release DLL.
I know the background behind my the Release version was chosen for UE4. I accept the argument, it makes sense for UE4 itself, but custom code still needs that debug functionality to run properly.
But that’s not all, even if I switch to Multithreaded Runtime Release DLL, it seems I have to disable _DEBUG macro for my debug builds to make it link with Multithreaded Runtime Release DLL and Unreal Engine. Which, I suspect, renders my application missing debug configuration altogether. That sounds like unreasonable sacrifice.
Could anyone guide me how do we force UE4 and UBT build projects to build using Debug CRT?
I build from sources. I tried just now 64 bit version build and I see no difference in error messages:
1>client.lib(main_state_machine.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘2’ doesn’t match value ‘0’ in Engine.h.obj
1>client.lib(main_state_machine.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MDd_DynamicDebug’ doesn’t match value ‘MD_DynamicRelease’ in Engine.h.obj
1>client.lib(boss_button.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘2’ doesn’t match value ‘0’ in Engine.h.obj
1>client.lib(boss_button.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MDd_DynamicDebug’ doesn’t match value ‘MD_DynamicRelease’ in Engine.h.obj
1>client.lib(asio_net.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘2’ doesn’t match value ‘0’ in Engine.h.obj
1>client.lib(asio_net.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MDd_DynamicDebug’ doesn’t match value ‘MD_DynamicRelease’ in Engine.h.obj
Not even Epic uses debug CRT runtime by default. There really isn’t any point, for the reasons outlined in the option for enabling it:
// By default we use the Release C++ Runtime (CRT), even when compiling Debug builds. This is because the Debug C++
// Runtime isn't very useful when debugging Unreal Engine projects, and linking against the Debug CRT libraries forces
// our third party library dependencies to also be compiled using the Debug CRT (and often perform more slowly.) Often
// it can be inconvenient to require a separate copy of the debug versions of third party static libraries simply
// so that you can debug your program's code.
bDebugBuildsActuallyUseDebugCRT = false;
Incidentally, johny5.coder, this option is what you would want to change to use debug CRT. You can find it in BuildConfiguration.cs.
Sorry for rant, I agree that Unreal Engine does not need that, unfortunately this requirement spreads to all linked to it libraries and applications, which makes it a bit inconvenient to debug memory related issues, like dangling pointer access and so on.
I wasn’t even aware that TargetRules has a bDebugBuildsActuallyUseDebugCRT variable. I don’t think that one is “low level” enough to carry over to the engine – most likely it is meant to be used for any module dependencies pulled at a game module level, not engine level.
Try changing the actual engine variable in BuildConfiguration.cs. bDebugBuildsActuallyUseDebugCRT is tagged as XmlConfig, so you can either:
Modify Engine/Saved/UnrealBuildTool/BuildConfiguration.xml to add:
You must have misconfiguration with your library setup. You have to write “3rd party library” c# build script. That will allow you to build dependencies together with your Unreal project, as well as link in and load correct .pdb files on startup. In case if something fails with .pdb, visual studio always have an option to load them manually for your libs after startup. You will have to only provide correct paths.
So when I link the debug libraries I get the same errors you were getting i.e. the ones with _ITERATOR_DEBUG_LEVEL mismatch. If I enable the bDebugBuildsActuallyUseDebugCRT in the xml file in the Engine folder and add corresponding variables in my build script to set bDebugBuildsActuallyUseDebugCRT to true. I start getting unresolved symbols such as _RTC_Shutdown etc. I am quite stuck. What version of engine and Visual studio are you using to build if I may ask ? I am currently trying this with 4.10.2 and the launcher build. Perhaps that’s the issue. Currently compiling a debug version of 4.11 preview 5 on my other machine however my project isn’t compatible with 4.11 at the moment, so I am not sure how easy for me it would be test with that.
Also, I have created a 3rd party library c# build script as you specified.
So it’s all about configuration and project settings you build your projects with.
Another hidden caveat is that 32 bit build uses 4 bytes alignment, 64 bit - 8 bytes alignment.
At first, if it’s getting very hard, you may pretty much include your sources as one big cpp file (all inclusive), with Unreal precompiled header included first, and then disabling their magic “check()” macro.
I would recommend start with default half-empty project and make it link in with C# build script.
I use Visual Studio 2013, UE4.11.
I managed to compile my stuff as standalone project, but it has it’s own drawbacks: Unreal’s build system does not try to detect changes in external libs, so force link sometimes is required.
I attach my C# build file here:
The project.Target.cs and projectEditor.Target.cs should contain these:
public class TachyonWarsTarget : TargetRules
public TachyonWarsTarget(TargetInfo Target)
bDebugBuildsActuallyUseDebugCRT = true;
Type = TargetType.Game;
Check also your solution configurations, what (debug or release/win32-64) build is used for every project at configuration you’re using. Make sure output folders do not overlap.
VS2013 starts working crappy the moment you start editing configs for so many projects simultaneously so I found more convenient to edit .sln file directly.