Hello
I m building my plugin and the demo game for UE5.6 first time. I m facing the error as posted above. I m attaching the logs with errors.
Previous versions like UE 5.5 or UE 5.4 did not have this issue. Is there flags that need to be passed to get this working?
no
Hey there,
Please refer to the following [Content removed] as I believe it’s the same case. I have a sneaking suspicion that your plugin has auto in a public API, and you have a lower language spec depending on this.
Julian
Thanks for the response. I am not seeing anywhere in the code where lower language (example cpp17) is used for compilation. Is there a place I can check in the intermediate files what compile options are used during the build?
We migrated to cpp20 a few months back and the above error should not occur.
I also don’t see templated auto being used in our plugin. I am thinking the plugin is trying to call functionalities in UObjectGlobals.h that has templated auto. as below.
constexpr static inline uint32 BuildMask(auto… Types)
{
return (0 | … | BuildMask(Types));
}
I found some files with *.rsp extenstion that seems to hold the compile flag and I notice the flag /std:c++17 exists. I would like to know how the build got the flag and where its coming from. I m not seeing that in my plugin or the demo game which I m trying to build.
Is there any module in UE thats declaring this flag?
In your visual studio solution, you can search for references of “Cpp17” - CppCompileEnvironment.cs has the enum. It can be configured at a target level, or a build module level. Cpp20 is the default in 5.6. The following is in Target Rules:
[CommandLine("-CppStd")] [XmlConfigFile(Category = "BuildConfiguration")] public CppStandardVersion CppStandard { #pragma warning disable CS0618 // Type or member is obsolete get => CppStandardPrivate ?? (DefaultBuildSettings < BuildSettingsVersion.V4 ? CppStandardVersion.Cpp17 : CppStandardVersion.Default); #pragma warning restore CS0618 // Type or member is obsolete set => CppStandardPrivate = value; } private CppStandardVersion? CppStandardPrivate;Verify your DefaultBuildSettings version as well in order to see what it’s being set to, or check your BuildConfiguration.xml to see if it’s annotated here. I’d also add in a breakpoint if you must, and build via visual studio with UnrealBuildTool as your startup project. Simply set the command line arguments to be passed in as your target, platform and config.
E.g. UnrealEditor Win64 Development
You should be able to breakpoint within the CppCompileEnvironment & TargetRules to see what it’s being resolved to.
If nothing jumps out, I’ll need to see the module that is failing to build, along with some RSP file associated with it. Whatever is including that UObjectGlobals.h has it’s module resulting in a C++17 CPPCompileEnvironment.
Julian
Hello Julian. Thanks for the info. I was able to put some break points in the code.
The errors went away when I added the following line to my game.build.cs and plugin.build.cs file.
CppStandard = CppStandardVersion.Cpp20;
However, I had to modify the engine under D:\UE5.6\Engine\Source\Programs\UnrealBuildTool\Platform\Windows\VCToolChain.cs.
I had to add this single line to fix some char8_t conversion errors. (Some of the libraries that our plugin use still does not support this cpp20 feature.)
switch (CompileEnvironment.CppStandard) { case CppStandardVersion.Cpp17: Arguments.Add("/std:c++17"); break; case CppStandardVersion.Cpp20: Arguments.Add("/std:c++20"); Arguments.Add("/Zc:char8_t-"); //** This is the line added to fix some errors. break; case CppStandardVersion.Latest: Arguments.Add("/std:c++latest"); break; default: throw new BuildException($"Unsupported C++ standard type set: {CompileEnvironment.CppStandard}"); }
Originally in my editor.target.cs file, I had the following additional compile arguments added.
AdditionalCompilerArguments += "/std:c++20 /Zc:char8_t-";
However, for UE5.6, the above line did not help in fixing the issue we were discussing.
I don’t want to modify the engine file to get this working, since the plugin we are building is used by many game teams and we cant force them to change the engine files.
My question is, is there any way I can pass the compile arguments through plugin.build.cs file while building the plugin. It seems the ModuleRules with which the plugin is derived from, does not have AdditionalCompilerArguments variable to hold the compile arguments.
I just saw the ticket enter the opened state, supposedly with a licensee response - but I can’t see it for some reason. Please let me know if I’ve missed something!
Julian
I replied back to your response. I needed some help.
In short, is there any way I can pass the compile arguments through plugin.build.cs file and game.build.cs file while building them. It seems the ModuleRules with which the plugin or the game build file is derived from, does not have AdditionalCompilerArgumentsvariable to hold the compile arguments.
*Build.cs files (Modules) do not have access to the AdditionalCompilerArguments; it will be your host project’s target file that you’re compiling everything within.
If you send your actual UBT invocation, I could provide a little more insight on where to look.
Julian
It seems the compile args presented in the host project’s target file is not picking up in all cases.
For example, I did mention this flag. /Zc:char8_t- in the target file, but still the compiler was throwing errors related to char8_t conversion. The only way I can get rid of the errors is to mention that in VCToolsChain.cs file as mentioned.
I m not sure on the UBT invocation. I built through VS and ran through VS 2022. Do you mean the command line args that are configured in the project properties?
I m attaching the screen shot.
When you build through Visual studio, a UBT log is created. This will have everything in it regarding the command line invocation, and environment.
As an example from my unreal 5-5 build environment. building from Visual Studio yields this:
12>Running UnrealBuildTool: dotnet "..\..\Engine\Binaries\DotNET\UnrealBuildTool\UnrealBuildTool.dll" -Target="UnrealEditor Win64 Development" -Target="ShaderCompileWorker Win64 Development -Quiet" -WaitMutex -FromMsBuild -architecture=x64 12>Log file: D:\p4\ue55\Engine\Programs\UnrealBuildTool\Log.txtI would like to see those lines, and the full Log.txt contents.
Also, please attach the Target, and Build files related to the build target that you see in the log (so for my example above, I’d want the UnrealEditor.Target.cs file, and any module’s build.cs file that has this issue). These are highly relevant to what’s going on here. Fundamentally speaking, AdditionalCompilerArguments will be merged into the compile environment. Have you been issuing clean builds inbetween?
Julian
Hello Julian.
I m attaching files requested.
I have been doing clean builds. The below changes need to be done in order to successfully compile our plugin and project.
Arguments.Add(“/std:c++20”);
Arguments.Add(“/Zc:char8_t-”);
I have attached the following file.
My intention is to not make any engine changes, viz, changes in VCToolChain.cs file and somehow carry over that change to the plugin or the game project side.
THanks.
Hi there,
Only the build file has been attached here. You’ll need to combine all into a zip file unfortunately as I don’t think multiple attachments is supported.
Edit: And please attach the RSP files for the compilation unit where the /Zchar8_t is not being added in (without the VCToolChain.cs modification).
As I mentioned before, you should be seeing the /Zc:chart8_t should be propagated through via the AdditionalCompilerArugments.
You should also not have to specify std:c++20. As I have stated before, this is the default; I suspect there is something within the Target file that’s driving this.
Julian
Sure. I ll disable the engine changes and will upload the rsp as well along with others.
On another note, when I compile for xbsx, I m seeing this error
The 'MSAAppId' or 'TitleId' element in the MicrosoftGame.config is missing. If one of these values is specified, then they must both be specified when using configVersion >= 1.
In previous engine versions, it seems that I was able to disable this error, by downgrading the MicrosoftGame.Config version in project settings. I m not seeing such a setting in this version. Has that been removed or moved? Cant we get away with just providing Title Id and not MSAAppId?
Hey there,
I’m not sure on that one; we’d probably need a new ticket and redirect that to the console group.
Julian
I m attaching the zip file that contains
The rsp files has entry for stdc++20. This is because I added the below line in my game build.cs file. Otherwise it would have an entry for stdc++17. I did not attach the plugin file here due to security reason, but plugin file also needs the below entry to get it compiled.
CppStandard = CppStandardVersion.Cpp20;With this set up, the game is throwing char8 conversion errors. If I add the compile argument to VCToolChain.cs file as mentioned before, everything works fine. Please let me know if any other information needed. I m ok with live debugging session if needed. Thanks for your help.
Hey there,
Can you please try adding the following to your .Target file?
DefaultBuildSettings = BuildSettingsVersion.V5;
For posterity I’ve been able to add AdditionalCompilerArguments (/Zc:char8_t- specifically) and have seen them be propagated all the way through to my module’s merged response files (*.rsp).
Julian
Hi Julian
Adding that did not help in adding the compile flag into the rsp file.
I see the errors have reduced, but unable to compile yet without making any change to the engine file.
Have u seen this thread that I had before.
[Content removed]
The compile args need to be passed in an order for it to work. Is that bug playing any part here?
Thanks
Hey there,
I can have a look at the referenced ticket. Generally speaking, you should absolutely declare your DefaultBuildSettings in your target. This is highly related to the previous C++ version issues and will insulate you in the future. In setting your defaultBuildSettings to V5, you should be able to stop passing the C++20 argument through.
I’ll see what could be going on regarding ordering.
CC: [mention removed] since I will be on vacation tomorrow until July 15th.
Julian
Hey there,
So just as an example:
`// Copyright Epic Games, Inc. All Rights Reserved.
using UnrealBuildTool;
using System.Collections.Generic;
using System;
public class BuildPipelineHarnessTarget : TargetRules
{
public BuildPipelineHarnessTarget(TargetInfo Target) : base(Target)
{
Type = TargetType.Game;
bOverrideBuildEnvironment = true;
CppStandard = CppStandardVersion.Cpp20;
AdditionalCompilerArguments += “/Zc:char8_t-”;
ExtraModuleNames.Add(“BuildPipelineHarness”);
bWarnAboutMonolithicHeadersIncluded = true;
}
}`Will yield an RSP of:
"Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Source/SecondaryModule/SecondaryModule.cpp" @"Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.Shared.rsp" /FI"Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/Definitions.h" /Fo"Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.cpp.obj" /experimental:log "Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.cpp.sarif" /sourceDependencies "Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.cpp.dep.json" /d2ssa-cfg-question- /Zc:inline /nologo /Oi /FC /diagnostics:caret /c /Gw /Gy /utf-8 /wd4819 /DSAL_NO_ATTRIBUTE_DECLARATIONS=1 /permissive- /Zc:strictStrings- /Zc:__cplusplus /D_CRT_STDIO_LEGACY_WIDE_SPECIFIERS=1 /D_SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS=1 /D_DISABLE_EXTENDED_ALIGNED_STORAGE /Ob2 /d2ExtendedWarningInfo /Ox /Ot /GF /errorReport:prompt /D_HAS_EXCEPTIONS=0 /DPLATFORM_EXCEPTIONS_DISABLED=1 /Z7 /MD /bigobj /fp:fast /Zo /Zp8 /W4 /wd4244 /wd4838 /TP /GR- /std:c++20 /Zc:preprocessor /wd5054 /Zc:char8_t-Any the following will generate the ordered list:
`// Copyright Epic Games, Inc. All Rights Reserved.
using UnrealBuildTool;
using System.Collections.Generic;
using System;
public class BuildPipelineHarnessTarget : TargetRules
{
public BuildPipelineHarnessTarget(TargetInfo Target) : base(Target)
{
Type = TargetType.Game;
bOverrideBuildEnvironment = true;
CppStandard = CppStandardVersion.Cpp20;
AdditionalCompilerArguments += “/std:c++20 /Zc:char8_t-”;
ExtraModuleNames.Add(“BuildPipelineHarness”);
bWarnAboutMonolithicHeadersIncluded = true;
}
}``“Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Source/SecondaryModule/SecondaryModule.cpp”
@“Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.Shared.rsp”
/FI"Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/Definitions.h"
/Fo"Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.cpp.obj"
/experimental:log “Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.cpp.sarif”
/sourceDependencies “Z:/EngineSyncRoot//Sandbox/DevRel/DevTools/Intermediate/Build/Win64/x64/BuildPipelineHarness/Development/SecondaryModule/SecondaryModule.cpp.dep.json”
/d2ssa-cfg-question-
/Zc:inline
/nologo
/Oi
/FC
/diagnostics:caret
/c
/Gw
/Gy
/utf-8
/wd4819
/DSAL_NO_ATTRIBUTE_DECLARATIONS=1
/permissive-
/Zc:strictStrings-
/Zc:__cplusplus
/D_CRT_STDIO_LEGACY_WIDE_SPECIFIERS=1
/D_SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS=1
/D_DISABLE_EXTENDED_ALIGNED_STORAGE
/Ob2
/d2ExtendedWarningInfo
/Ox
/Ot
/GF
/errorReport:prompt
/D_HAS_EXCEPTIONS=0
/DPLATFORM_EXCEPTIONS_DISABLED=1
/Z7
/MD
/bigobj
/fp:fast
/Zo
/Zp8
/W4
/wd4244
/wd4838
/TP
/GR-
/std:c++20
/Zc:preprocessor
/wd5054
/std:c++20 /Zc:char8_t-`This is on a vanilla engine sync of 5.6. Are there any other divergences in UBT on your end (Including the VCToolChain.cs - even in the other ticket the need for adding the Cpp20 is suspect; you should be specifying buildSettings v5 - the engine is c++ 20 compliant)? In your scenario I’d be trying to remove as many Target rules property modifications as I possibly could at the moment.
Edit
Also, I’ve tested this with the Plugin and it appears as though the AdditionalCompileArugments has also cascaded to the *.rsp files of that module as well.
So compile errors not-withstanding, it’s still unclear to me why your Target setup is not propagating the compile arguments to the RSP files.
Julian