Building engine with Debug Runtime library

anonymous_user_3fdeed1c1 · March 18, 2015, 3:10am

Hello,

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?

Mikand79 · March 18, 2015, 8:45am

Clone the UE4 source from github https://github.com/EpicGames/UnrealEngine, call setup & generateprojectfiles and then build UE4Editor in the Debug solution configuration for Win64.

anonymous_user_3fdeed1c1 · March 18, 2015, 2:14pm

Yes, sorry, I forgot to mention.

Unreal Engine 4.6.

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

anonymous_user_4fe9f58b1 · March 18, 2015, 2:25pm

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.

anonymous_user_3fdeed1c1 · March 18, 2015, 9:56pm

Thank you very much, I will try that.

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.

Mikand79 · March 19, 2015, 10:40am

cmartel;250518:

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;

Thank you very much.

anonymous_user_3fdeed1c1 · March 19, 2015, 11:00am

How to actually enable the flag?

I tried to enable it at



public class TachyonWarsTarget : TargetRules
{
	public TachyonWarsTarget(TargetInfo Target)
	{
		bDebugBuildsActuallyUseDebugCRT = true;

		Type = TargetType.Game;
	}

But when I build “Debug Client” configuration I see that at (UEBuildWindows.cs : line 411):


   bool bUseDebugCRT = InBuildTarget.Configuration == UnrealTargetConfiguration.Debug && BuildConfiguration.bDebugBuildsActuallyUseDebugCRT;

Variables has these values:
InBuildTarget.Configuration = Development
BuildConfiguration.bDebugBuildsActuallyUseDebugCRT = false

even though InBuildTarget.Rules.bDebugBuildsActuallyUseDebugCRT = true

Because of that I still get same linker errors.

How do I affect InBuildTarget.Configuration and BuildConfiguration.bDebugBuildsActuallyUseDebugCRT?

anonymous_user_4fe9f58b1 · March 19, 2015, 4:14pm

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:


<bDebugBuildsActuallyUseDebugCRT>true</bDebugBuildsActuallyUseDebugCRT>

Or, if you’re lazy like me, just go in BuildConfiguration::LoadDefaults() and set it there directly.

anonymous_user_3fdeed1c1 · March 19, 2015, 8:22pm

Big thanks for your sincere support.

Trying this today night.

darkZ · February 21, 2016, 6:10pm

Sorry for resurrecting this old thread back to life, but did you ever manage to step through your external library code in debug mode ?

anonymous_user_3fdeed1c1 · February 21, 2016, 8:46pm

Sure, no problem.

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.

darkZ · February 21, 2016, 10:12pm

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.

darkZ · February 22, 2016, 1:16am

Is there a link you can provide somewhere on how to do this ?

darkZ · February 22, 2016, 5:43am

I have now built the Release library with debuging symbols and that roundabout although with its disadvantages will have to do for now, unless I can figure out to link against true Debug binaries.

anonymous_user_3fdeed1c1 · February 22, 2016, 10:29am

Regarding _RTC_Shutdown, Googling spits me this:
.com/
https://social.msdn.microsoft.com/Forums/vstudio/en-US/897958b6-4a3e-4d56-a954-aefc04efdb43/error-lnk2001?forum=vclanguage

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:

// Copyright 1998-2014 Epic Games, Inc. All Rights Reserved.
using System;

using UnrealBuildTool;

public class ClientImpl : ModuleRules
{
public ClientImpl(TargetInfo Target)
{
Type = ModuleType.External;
	PublicIncludePaths.Add("../../../client/src");
	PublicIncludePaths.Add("../../../common/src");

	string clientLibPath = "../../../client/projects/";
	string commonLibPath = "../../../common/projects/";

	string configSuffix = "";

	switch(Target.Platform)
	{
		case UnrealTargetPlatform.Win32:
			configSuffix += "Win32/";
// PublicAdditionalLibraries.Add(“…/…/…/engine/OpenAL/libs/Win32/OpenAL32.lib”);
PublicAdditionalLibraries.Add(“…/…/…/engine/ZLib/build/Win32/zlib.lib”);
PublicLibraryPaths.Add(“…/…/engine/boost/build/Win32/”);
break;
		case UnrealTargetPlatform.Win64:
			configSuffix += "x64/";
// PublicAdditionalLibraries.Add(“…/…/…/engine/OpenAL/libs/Win64/OpenAL32.lib”);
PublicAdditionalLibraries.Add(“…/…/…/engine/ZLib/build/x64/zlib.lib”);
PublicLibraryPaths.Add(“…/…/engine/boost/build/x64/”);
break;
}
	switch (Target.Configuration)
	{
		case UnrealTargetConfiguration.Debug:
		case UnrealTargetConfiguration.DebugGame:
			configSuffix += "Debug/";
			break;

		case UnrealTargetConfiguration.Development:
		case UnrealTargetConfiguration.Shipping:
			configSuffix += "Release/";
			break;

		default:
			throw new Exception( String.Format("Build configuration is not supported yet: {0}", Target.Configuration) );
	}

	PublicAdditionalLibraries.Add("../../../engine/lua/build/" + configSuffix + "lua.lib");
	PublicAdditionalLibraries.Add("../../../engine/luabind/build/" + configSuffix + "luabind.lib");
	PublicAdditionalLibraries.Add(clientLibPath + configSuffix + "client.lib");
	PublicAdditionalLibraries.Add(commonLibPath + configSuffix + "common.lib");

}
}

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.