致命错误 LNK1179:无效或损坏的文件:重复的 COMDAT '_IID_IXMLDOMImplementation' [英] fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '_IID_IXMLDOMImplementation'

查看:98
本文介绍了致命错误 LNK1179:无效或损坏的文件:重复的 COMDAT '_IID_IXMLDOMImplementation'的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在链接我的项目时遇到了这个错误,

<块引用>

COMMUNICATION.obj:致命错误 LNK1179:无效或损坏的文件:重复 COMDAT '_IID_IXMLDOMImplementation'

问题的根源是什么?

解决方案

这是一个棘手的问题.

问题是生成的符号太长,存在歧义:

//...void MyVeryLongFunctionNameUnique_0(void);void MyVeryLongFunctionNameUnique_1(void);//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^//(示例最大符号长度由链接器看到)

在这种情况下,链接器将这两个函数视为"相同",因为使它们唯一"的部分比最大符号长度更长.

这可能发生在至少三种情况:

  • 您的符号名称太长",无法被认为是链接器独有的,但对于编译器来说可能没问题(例如当您从许多嵌套模板中展开时)
  • 你做了一些无效 C++ 的诡计",它通过了编译器,但你现在有一个无效的 *.obj,它阻塞了链接器.
  • 您指定了重复的未命名"类/结构,链接器无法解析它们.
  • ===[UPDATE]===,这不是您的错,而是编译器和/或链接器的内部问题(有关可能的解决方法,请参见下文).

根据问题(上文),您可以增加"您的符号长度(通过限制您的减少符号长度),或修复您的代码以使其有效(明确)C++.

Microsoft 在以下位置(最低限度)描述了此错误:

注意:可以使用 /H 选项设置此最大符号长度,请参阅:http://msdn.microsoft.com/en-us/library/bc2y4ddf(v=vs.90).aspx

  • 推荐:检查是否在命令行中使用了 /H.如果是,删除它(不指定max-symbol-length,默认为2,047/H只能DECREASE这个长度,而不是增加它).

但是,您可能通过 /Gy 选项(函数级链接)触发它,这可能通过 /Z7/Zi/ZI:http://msdn.microsoft.com/en-us/library/958x11bc(v=vs.90).aspx

一个讨论这个问题的 MSDN 线程是:

此线程表明可以使用invalid-C++-code-that-c​​ompiles"(您获得 *.obj)来触发此问题,但使用无效-*.obj 阻塞链接器(此示例尝试将 main 用作函数和模板):

===[更新]===

我之前应该说这个,因为我怀疑,但我现在有更多信息:这可能不是你的错,编译器和/或链接器似乎有问题触发了这个错误.尽管事实上所有失败的关系中唯一的共同点就是你自己.

回想一下以上列表"适用(这可能是你的错).但是,如果这不是你的错",这里是当前运行列表(我确信此列表不完整).

  • 您的 *.ilk 文件(中间链接文件)中存在内部错误/损坏.删除它并重建.
  • 您已打开 /INCREMENTAL 进行链接,但不知何故增量链接不适用于您的项目,因此您应该将其关闭并重新构建 (Project-Properties=>Configuration Properties=>Linker=>General=>Enable Incremental Linking [设置为No"(/INCREMENTAL:NO)]
  • 您在使用COMDAT 折叠"的优化"方面存在问题.您可以通过转到Project Proerties=>Configuration Properties=>Linker=>Optimization=>Enable COMDAT Folding,设置为Remove Redundant COMDATs (/OPT:ICF)

这是一个有趣的帖子,来自一个有时可以链接,有时不能,通过注释输入/注释几行代码的人.这不是代码的问题——他只是无法始终如一地链接,而且在某些晦涩的用例下,编译器和/或链接器似乎存在内部问题:

来自非平凡网络搜索的其他观察:

  • 这个问题似乎并不罕见
  • 似乎与某种形式的template<>使用
  • 有关
  • 其他人似乎在发布"构建中看到了这个问题,而调试"构建没有此问题(但在许多情况下,调试"构建中也会出现此问题)
  • 如果链接在一台机器上失败",它可能会在另一台构建机器上成功"(不知道为什么,干净构建"似乎没有效果)
  • 如果您注释/注释特别重要的几行代码,并完成构建,并继续这样做直到所有代码再次取消注释,您的链接可能会成功(这似乎是可重复的)
  • 如果您在使用 MSVC2008 时遇到此错误,并且将代码移植到 MSVC2010,您仍然会遇到此错误

===[向世界好人的请愿书]===

如果您对此错误有其他意见,请在下面列出(作为其他答案,或作为此答案下方的评论).我有一个类似的问题,这不是我的错,而且这些变通办法都不适合我(尽管在某些情况下,它们似乎确实适用于他们项目中的其他人).

我要增加赏金,因为这让我发疯了.

===[更新+2]===

(叹气),这里有更多可以尝试的东西(显然对其他人有用,但对我不起作用):

  • 这个家伙改变了他的编译设置,它起作用了(来自 http://forums.codeguru.com/showthread.php?249603.html):

    Project->Settings->C++ tab, Debug cathegory: Inline function extension:从'None' 改为 'Only _inline>'.

  • 上面的线程引用了另一个必须重新安装 MSVC 的线程

  • 这可能与在可能不兼容的编译器和/或链接开关中链接具有细微差异"的模块有关.检查所有贡献库"是否使用完全相同的开关构建

以下是有关此错误/错误的更多症状/观察结果:

  • 上述问题的列表仍然适用
  • 该问题似乎在 MSVC2005 中开始出现",并且 MSVC2008 和 MSVC2010 的行为仍然相同(将代码移植到较新的编译器后仍会出现错误)
  • 重新启动 IDE,重新启动机器似乎对任何人都不起作用
  • 一个人说一个明确的清理"然后重新编译对他有用,但许多其他人说这对他们不起作用
  • 通常与增量链接"有关(例如,将其关闭)

状态:不开心.

===[更新+3:链接成功]===

Super-wacky-makes-no-sense 修复以成功发现链接!

这是(上面)的一个变体,在那里你摆弄代码直到编译器和/或链接器行为".不太好,可能需要这样做.

特定的单个链接器错误 (LNK1179) 用于 MyMainBody<>():

#include "MyClassA.hpp"#include "MyClassB.hpp"#include "MyClassC.hpp"#include "MyClassD.hpp"#include "MyMainBody.hpp"int main(int argc, char* argv[]){//使用函数模板作为主体",//实现是最简单的",实例化//一些本地的MyClass"实例,它们引用//彼此,并做一些初始化,//(~50行代码)////!!!MyMainBody<>()"的 LNK1179,损坏的名称约为 236 个字符//return MyMainBody(argc,argv);}

解决办法:

  • MyMainBody<>()template<>"转换为显式函数,LINK SUCCESS.

THIS FIX SUX,因为我需要其他实用程序中的其他类型的完全相同的代码,并且 MyMainBody<>() 实现非常重要(但大多是简单的)实例化和设置,必须以特定方式、特定顺序完成.

但是,嘿,现在这是一个临时的解决方法:在 MSVC2008 和 MSVC2010 编译器上确认(每个都有相同的 LNK1179 错误,应用解决方法后每个都成功链接).

这是编译器和/或链接器错误,因为代码是简单/正确的 C++"(甚至不是 C++11).

所以,我很高兴(我在全职工作了 2 周以上后得到了一个链接).但是,很失望(编译器和/或链接器在链接一个简单的模板时存在一个愚蠢的问题<>,我无法弄清楚如何解决这个用例).

进一步,赏金结束",但没有其他人愿意接受这个(没有其他答案?),所以看起来像+100"没有人.(重重叹息)

I am getting this single error when I am linking my project,

COMMUNICATION.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '_IID_IXMLDOMImplementation'

What is the source of the problem?

解决方案

This is a tricky one.

The issue is that the symbol(s)-generated is too-long, and an ambiguity exists:

  //...
  void MyVeryLongFunctionNameUnique_0(void);
  void MyVeryLongFunctionNameUnique_1(void);
  //   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  //   (example max-symbol-length-seen-by-linker)

In this case, the linker "sees" these two functions as the "same", because the part that makes them "unique" is longer-than-the-max-symbol length.

This can happen in at least three cases:

  • Your symbol names are "too-long" to be considered unique to the linker, but may have been fine for the compiler (such as when you expand-out from many nested templates)
  • You did some "trickery" that is invalid C++, and it passed the compiler, but you now have an invalid *.obj, and it chokes the linker.
  • You specified duplicate "unnamed" classes/structs, and the linker cannot resolve them.
  • ===[UPDATE]===, It's not your fault, it's an internal problem with the compiler and/or linker (see below for possible work-arounds).

Depending on the issue (above), you can "increase" your symbol-length (by limiting-your-decrease-of-symbol-length), or fix your code to make it valid (unambiguous) C++.

This error is (minimally) described by Microsoft at:

NOTE: This max-symbol-length can be set with the /H option, see: http://msdn.microsoft.com/en-us/library/bc2y4ddf(v=vs.90).aspx

  • RECOMMEND: Check to see if /H is used on your command-line. If it is, delete it (do not specify max-symbol-length, it will default to 2,047, the /H can only DECREASE this length, not increase it).

However, you probably triggered it through the /Gy option (function-level-linking), which was probably implied through one of /Z7, /Zi, or /ZI: http://msdn.microsoft.com/en-us/library/958x11bc(v=vs.90).aspx

One MSDN thread that talks about this issue is:

This thread suggests that it's possible to trigger this issue with "invalid-C++-code-that-compiles" (you get your *.obj), but that invalid-*.obj chokes the linker (this example attempts to use main as both a function and as a template):

===[UPDATE]===

I should have said this before, because I suspected, but I now have more information: It might not be your fault, there seems to be an issue in the compiler and/or linker that triggers this error. This is despite the fact that the only common denominator in all your failed relationships is you.

Recall that the "above-list" applies (it MIGHT be your fault). However, in the case where, "it's not your fault", here's the current-running-list (I'm confident this list is NOT complete).

  • There is an internal error/corruption in your *.ilk file (intermediate-link-file). Delete it and rebuild.
  • You have /INCREMENTAL turned on for linking, but somehow that incremental-linking is not working for your project, so you should turn it off and rebuild (Project-Properties=>Configuration Properties=>Linker=>General=>Enable Incremental Linking [set to "No" (/INCREMENTAL:NO)]
  • There's a problem with "Optimization" for "COMDAT Folding" in your use. Your can "Remove Redundant COMDATs" by going to Project Proerties=>Configuration Properties=>Linker=>Optimization=>Enable COMDAT Folding, set to "Remove Redundant COMDATs (/OPT:ICF)

Here's an interesting thread from a guy who sometimes can link, and sometimes not, by commenting in/out a couple lines of code. It's not the code that is the problem -- he just cannot link consistently, and it looks like the compiler and/or linker has an internal problem under some obscure use case:

Other observations from a non-trivial web search:

  • this problem appears to be non-rare
  • it seems to be related to some form of template<> use
  • others seem to see this problem with "Release" build when it did not have this problem with "Debug" build (but it is also seen on the "Debug" build in many cases)
  • if the link "fails" on one machine, it may "succeed" on another build machine (not sure why, a "clean-build" appears to have no effect)
  • if you comment in/out a particularly significant couple-lines-of-code, and finish your build, and keep doing this until all the code is un-commented again, your link may succeed (this appears to be repeatable)
  • if you get this error with MSVC2008, and you port your code to MSVC2010, you will still get this error

===[PETITION TO THE GOOD PEOPLE OF THE WORLD]===

If you have other observations on this error, please list them below (as other answers, or as comments below this answer). I have a similar problem, and it's not my fault, and none of these work-arounds worked for me (although they did appear to work for others in their projects in some cases).

I'm adding a bounty because this is driving me nuts.

===[UPDATE+2]===

(sigh), Here's more things to try (which apparently work for others, but did not work for me):

  • this guy changed his compile settings, and it worked (from thread at http://forums.codeguru.com/showthread.php?249603.html):

    Project->Settings->C++ tab, Debug cathegory: Inline function expansion: change from 'None' to 'Only _inline'.

  • the above thread references another thread where the had to re-install MSVC

  • it is possibly related to linking modules with "subtle-differences" in possibly-incompatible compiler and/or link switches. Check that all the "contributing libs" are built with the exact same switches

Here's some more symptoms/observations on this error/bug:

  • list(s) for above issues still apply
  • the issue seems to "start-showing-up" with MSVC2005, and continues with the same behavior for MSVC2008 and MSVC2010 (error still occurs after porting code to newer compilers)
  • restarting IDE, rebooting machine doesn't seem to work for anybody
  • one guy said an explicit "clean" followed by a recompile worked for him, but many others say it did not work for them
  • is often related to "incremental linking" (e.g., turn it off)

Status: No joy.

===[UPDATE+3 : LINK SUCCESS]===

Super-wacky-makes-no-sense fix to successfully link discovered!

This is a variation on (above), where you "fiddle-with-the-code-until-the-compiler-and/or-linker-behaves". NOT GOOD that one might need to do this.

Specific single linker-error (LNK1179) was for MyMainBody<>():

#include "MyClassA.hpp"
#include "MyClassB.hpp"
#include "MyClassC.hpp"
#include "MyClassD.hpp"
#include "MyMainBody.hpp"

int main(int argc, char* argv[])
{
  // Use a function template for the "main-body", 
  // implementation is "mostly-simple", instantiates 
  // some local "MyClass" instances, they reference 
  // each other, and do some initialization,
  // (~50 lines of code)
  //
  // !!! LNK1179 for `MyMainBody<>()`, mangled name is ~236 chars
  //
  return MyMainBody<MyClassA,MyClassB,MyClassC,MyClassD>(argc,argv);
}

THE FIX:

  • Convert MyMainBody<>() from a "template<>" to an explicit function, LINK SUCCESS.

THIS FIX SUX, as I need the EXACT-SAME-CODE for other types in other utilities, and the MyMainBody<>() implementation is non-trivial (but mostly simple) instantiations-and-setups that must be done in a specific way, in a specific order.

But hey, it's a temporary work-around for now: Confirmed on MSVC2008 and MSVC2010 compilers (same LNK1179 error for each, successful link on each after applying the work-around).

THIS IS A COMPILER AND/OR LINKER ERROR, as the code is "simple/proper-C++" (not even C++11).

So, I'm happy (that I got a link after suffering full-time for 2+weeks). But, disappointed (that the compiler and/or linker has a STUPID GLARING PROBLEM with linking a SIMPLE TEMPLATE<> in this use-case that I couldn't figure out how to address).

FURTHER, the "Bounty Ended", but nobody else wanted to take this on (no other answers?), so looks like "+100" goes to nobody. (heavy-sigh)

这篇关于致命错误 LNK1179:无效或损坏的文件:重复的 COMDAT '_IID_IXMLDOMImplementation'的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆