使用/GL选项时，向后兼容性会受到破坏

Question

为了在ARM64设备上构建我们的应用程序，我们将VS 2017 15.5.7升级到15.9.6版本。在那之后，使用/GL标志构建的库(15.9.6)现在会在被15.5.7构建的测试应用程序中抛出“未识别的标志”错误，如下所示：

1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed

在项目设置中禁用“整个程序优化(/GL)”，客户端构建就能通过。

请问有谁能查看一下从15.5.7版本到现在发生了什么变化，以引起此链接错误？ 此外，最佳优化的建议项目设置是什么。

- Vinay Gupta

Answer 1

当您使用此选项时，向后兼容性确实会受到破坏。

官方文档：

整个程序优化允许编译器使用程序中所有模块的信息进行优化。没有整个程序优化，则是按模块（compiland）为基础进行优化。

还有，尽管它提到了 Visual Studio 2015 和 Visual Studio 2017之间的差异, 它仍然是官方支持的。

以下情况下无法保证二进制兼容性：

1. 使用/GL编译器开关编译静态库或目标文件时。
2. 当使用比应用程序编译和链接所用的工具集版本更高的工具集构建库时。例如，使用编译器版本19.12编译和链接的程序可以使用使用19.0到19.12编译的库。此外，二进制兼容性仅存在于Visual Studio 2015和Visual Studio 2017之间；不支持将19.x程序与由Visual Studio 2013或更早版本生成的库进行链接。

但是，非官方地说：

使用此编译器选项，如果您的依赖项中有一个使用不同的编译器更新（即使只是一些小的更新），链接几乎肯定会失败。

事实上，/GL编译器选项在DLL和EXE之间的向后兼容性方面非常严格，以至于我们公司决定不再使用它。

我们有很多DLL，并且来自不同项目的可执行文件都已经构建好了。

简而言之，在调试时，我们有时需要使用较新的编译器构建exe，同时使用较旧的编译器编译的库。

这个标志就阻止了这样做。

可能有助于其他人的解决方案：

• 使用旧编译器重新构建旧库，不使用该标志
• 在保留该标志的情况下，使用新编译器重新构建旧库（这意味着每当出现新编译器时都要重新构建它们）
• 使用旧编译器重新构建新可执行文件（这意味着不进行编译器更新）

- Nadge25

---

感谢提供不同的解决方案。我们已经决定放弃这个标志并评估性能影响。 - Vinay Gupta