致命错误LNK1179：无效或损坏的文件：重复的COMDAT

Question

我正在VS2019上从源代码构建虚幻引擎4.27.0，但显示如下：

Module.UnrealEd.15_of_23.cpp.obj ： 致命错误 LNK1179： 无效或损坏的文件： 重复的 COMDAT ' '

从源代码构建已经需要 5 个多小时。

Answer 1

我只是与这个重复或损坏的 COMDAT 事情斗争了一段时间，我终于弄清楚了导致我的原因 - 在不了解您的项目的情况下，很难说它对您来说是什么，但这里是：

1. 我正在使用 c++ 语言构建：C++20、VS2022(但我在 vs2019 中也遇到了同样的情况)

2. 我正在启用实验性标准模块的情况下进行构建 - 对于像这样的花哨的东西：import std.core;

我

3. 有一些我刚刚 #include 的旧代码，我没有阅读关于这两种导入/包括方式如何在启用模块的情况下玩togeather的具体规则。我有一些看起来像这样的文件(但具有不同的类)

   
   // whatever.ixxexport module whatever;#include "oldHeaderFullOfTemplates.hpp"
import someNewCustomModule;

export class stuffWhatever {// ...}
   
   
   

这里的问题是，通过在导出模块行下方#including，我强制编译器将该内容包含在模块中......有点...根据我有限的理解，它必须为该标头中的所有内容创建新的、更长的唯一链接名称 * 所有时间您将其包含在任何模块中。无论如何，通过将我的
#include "oldHeaderFullOfTemplates.hpp"
移到我的
export module whatever;
上方

我所有愚蠢的Comdat错误都消失了。 另外 - 我对 c++20 模块的理解显然是......有限，所以如果我在上面撒谎，也许更多知识渊博的人可以纠正我这里正在进行的 wtf。 最后一个花絮是一个旧的VS编译器选项/H{number}它应该允许你选择一个长度(链接名称？)供链接器在决定某些内容重复之前考虑。不过，此选项已被弃用，即使在设置为非常高的数字之后，它也根本没有帮助我。

Answer 2

另一种可能的解决方案，灵感来自 mingw 的 gcc 中对类似问题的讨论：使用/GL标志进行编译，它执行整个程序优化。至少在我的情况下，它有效！

老实说，我不完全确定我是否理解我的情况中的问题是什么，所以我不会试图总结这个答案。由于我在 mingw 中使用 gcc 编译相同的代码时遇到了他们在那里描述的完全相同的问题，这就是让我怀疑我需要类似方法的原因。