CLion with UE 4.20, Command line error D8049

anonymous_user_0f59718a · July 24, 2018, 9:15pm

I am trying to use UE 4.20 with CLion 2018.1.6 on windows. After generating the project I had an issue with the CMake list, which contained file-paths not compatible with windows (single backslash). I fixed this manually, but then I ran into another issue when CLion tries to load the project.

This is what I get in the log:

“cl : Command line error D8049 : cannot execute ‘C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\Hostx86\x86\c1xx.dll’: command line is too long to fit in debug record”

Is anyone running CLion successfully on Windows with the shipped version of unreal? What am I missing in my setup?

gabis · July 31, 2018, 2:43pm

I have the same issue. You can make ‘production’ build though.
Change it in clion preferences > build, execution, deployment > cmake. Don’t know what are the implications.

velocius · October 3, 2018, 1:12am

Same issue here. The make file had incorrectly escaped paths which I tweaked manually.

Error looks the same

Command line error D8049 : cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.14.26428\bin\Hostx86\x86\c1xx.dll': command line is too long to fit in debug record

anonymous_user_b83de8481 · October 11, 2018, 9:33pm

Exactly the same problem. I created a symbolic link to the Engine files and the project files, which is very short, and it is still too long. It replaced more occurrences than characters allowed on the command line, btw. Why is it not using a file and putting everything there?

TheDreamCatcher · October 18, 2018, 12:29am

For anyone still having this issue, there is actually a bug inside the msvc compiler. the trick when using clion is to switch Build Type from Debug to Release. (Settings → Build, Execution, Deployment → CMake)

TheDreamCatcher · October 18, 2018, 10:27am

with UE there is no difference.

gabis · October 18, 2018, 10:25am

Yes! That works, but do you know what’s the difference using one or the other?

gabis · October 18, 2018, 10:59am

Thanks. Now i can keep using release mode without any concern

anonymous_user_dd8811ba · October 25, 2019, 10:18am

I found a way to fix this error, add bLegacyPublicIncludePaths = false; to your [ProjectName].Build.cs file (or whichever module is failing).

This requires you to fix all your header includes though, but that’s just healthy for your project.
The reason your build is failing is because legacy behavior is to append all public include paths to the build tool’s command line. This doesn’t scale and fails eventually as a project grows for tools with smaller commandline buffer. Turning off legacy include paths stops appending them to the command line at the cost of you having to put in the actual correct path for each header. But you’d want to have correct include paths anyways, right?

UE4 has a commandlet to help with fixing your include paths:
RunUAT.bat RebasePublicIncludePaths -Project="path/to/project.uproject" -UpdateDir="path/to/code" -Write

If you have many modules you might want to turn it on for all of them, but you can also put that same boolean into your *.Target.cs files to force it for all modules in your targets.