How to disable Warnings treated as Error flag for Compiling?

So im trying to compile my project but i keep running into the C2220 error.
looking this up it turns out that the /WX flag is enabled and is causing minor errors such as “conversion from x to y possible loss of data” to be treated as errors.
This is very annoying and limiting in compiling, is there any way to turn off the /WX flag?

Hello @alatnet,

Can you post the stack trace or error log? It should show which project is causing the issue, it might not be from your project but could be from another project.


Hi @alatnet,

Did you try running lmbr_waf configure again after you modified the wscript for your game to have the win_cxxflags entry with the new warning level?

    def build(bld):
# other settings ...
win_cxxflags = ['/W3']

Another alternative is to edit dev\Code\Tools\waf-1.7.13\lmbrwaflib\ and remove the /WX option from COMMON_COMPILER_FLAGS on line 101. Then run lmbr_waf configure again and build.

Hello @alatnet,

If you take a look at your project’s wscript file, there should be a flag under win_cxxflags that you can remove to disable warnings treated as errors. It would most likely be ‘/WX’ which would set the warning as errors flag or you could also modify the warning level to prevent it from happening.

Hope that helps!


No. It’s Lumberyard 1.5. I didn’t have this problem with

Tried adding /W3 to my flags but it didn’t knock out the /WX flag…

no, it’s my project. it compiles lumberyard itself fine but when compiling my project it has the /WX flag.

Edit: Heck, looking at the property pages of the project and the WAF section in there shows that the /WX flag is there under C Options and C++ Options.

pasted-image-at-2017-01-26-08-06-pm.pngDragonCrash team is also having this error on multiple machines. It appears to have worked on one of our machines when we tried re-installing the Windows 8.1 SDK:

Hey @NormaTu545, did that solve the issue for all the machines or just the one? Are you all still running in to this problem?

Hi Norma,

I spoke with you and the team on the phone the other night. Did reinstalling Windows SDK 8.1 help on all machines, or are some still broken? I hope to hear from you soon!

Al Murray :slight_smile:

Just the one. We couldn’t figure out what was wrong with the other installations, so our group just started from complete scratch again and reinstalled Visual Studio 2015 Community edition AND completely started over with Lumberyard 1.7 and its required SDKs too.

It took a really long time to get Lumberyard 1.7 eventually on 6 machines in the lab, but we’re relieved we can get back to work again!

@JasonLu1808 from the DragonCrash team has been the ultimate sport and has had to deal with 20+ re-install attempts for us.

Hi Al, thanks for reaching out, we managed to get 1.7 working on all our machines eventually after sacrificing 3 work days to resolving download issues. For some of the computers, we caught the fact that their install of Visual Studio 2015 Community edition DIDN’T have a C++ compiler checked during installation, and that caused the profile build to fail.

One would think that IDEs know that developers want a compiler by default, but in our case, we had to tell visual studio to install the darn thing in order to get the profile build going again!

My goodness. Well we’re glad you got the issue resolved. Please let us know how you get on.

Al :slight_smile:

Wow, that’s a frustrating experience for sure. I’m glad you are finally all sorted out. Let us know if you run into any more chanllenges.

For anyone who may be looking for this location in Lumberyard 1.12, this file is now located at dev\Tools\build\waf-1.7.13\lmbrwaflib\ (i.e. note the missing “Code” directory).