为了构建适用于ARM64设备的应用程序，我们将VS 2017 15.5.7升级到15.9.6版本。发布后，当由测试应用程序（在15.5.7上构建）使用时，使用/ GL标志构建的（15.9.6）库现在会引发“无法识别的标志”错误，如下所示：
1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed
一旦在项目设置中禁用了“整个程序优化（/ GL）”，客户端构建就会通过。
谁能检查从15.5.7版本更改到现在引发此链接错误的内容？ 此外，建议的最佳项目设置是什么。
答案 0 :(得分：3)
当您说使用此选项破坏了向后兼容性时，您是对的。
整个程序优化允许编译器使用程序中所有模块的信息进行优化。如果没有整个程序的优化，则优化是基于每个模块（compiland）进行的。
而且，即使被提及为between Visual Studio 2015 and Visual Studio 2017，也仍然是正式的：
在以下情况下不能保证二进制兼容性：
- 使用/ GL编译器开关编译静态库或目标文件时。
- 使用使用工具集构建的库时，该工具集的版本大于用于编译和链接应用程序的工具集。例如，被编译并与编译器版本19.12链接的程序可能会消耗从19.12到19.12为止编译的库。此外，二进制兼容性仅在Visual Studio 2015和Visual Studio 2017之间存在；其他情况下，二进制兼容性不存在。不支持将19.x程序与Visual Studio 2013或更早版本生产的库链接。
但非正式地说，我可以这样说：
使用此编译器选项，如果您的依赖项之一是使用其他编译器更新（甚至是一些次要更新）构建的，则链接肯定会失败。
实际上，/ GL编译器选项对于DLL和EXE之间的向后兼容性是如此严格，以至于我们决定不再在公司中使用它。
我们有很多DLL，并且EXEcutables构建在不同的项目上。
为了简短起见，在调试时，有时我们需要使用较新的编译器来构建exe，同时使用由较旧的编译器编译的库。
此标志阻止这样做。
可能对他人有帮助的解决方案：