Krazer

It might be a mix-match in the builds. The 2nd entry seems to imply that the engine is trying to load a debug version of the library but the library...

NM I think I was reading the above wrong, yeah looks like your take seems right, assuming `SharedPCH.Engine.NonOptimized.Cpp17.h.obj` is coming from the unreal engine. Have to dig through the cmake...

In that case, likely the build type is wrong https://github.com/caseymcc/UE4CMake/blob/0be0d4a380235f30ca60d2fbf9a4db3d32716c1a/Source/CMakeTarget.Build.cs#L243

You could remove that above line and see if it works then.

I went through the build system (at least for linux) to try and replicate the build configs exactly based on Unreal's build tool. However although the code is there, there...

replicating the build flags is the only safe way to use the std lib across library boundaries.

if you just add `-DCMAKE_BUILD_TYPE={Debug/Release/etc...}` to the `cmake_args` of `CMakeTarget.add(...)` it will notice it and force that build type, https://github.com/caseymcc/UE4CMake/blob/0be0d4a380235f30ca60d2fbf9a4db3d32716c1a/Source/CMakeTarget.Build.cs#L84

btw internally via the link above with the DebugGame. It is already using the Target.Configuration to determine what the cmake build should be. Just seems that although DebugGame says debug...

if you just change line 45 in nameof.hpp ctti::nameof().length() to ctti::nameof().size() it will compile, size is the same as length, definitely a bug in VS.

its really weird if I change the top one to size line 29 it will crash as well. The middle on at line 37 doesn't matter either way. I can...