Visual c++ C++；VS2008链接器错误（已定义），只需添加一个#include 我有一个应用于VS2008 C++的应用程序，它已经工作了很长时间了。 它由几个静态库项目组成，这些项目都链接到一个.exe中

在一些维护过程中，我在一个静态库项目中的一个.cpp文件中添加了一个额外的#include，导致exe（一个单独的项目）拒绝链接。如果我删除违规的#include（并尝试重新考虑维护更改），问题就解决了，但显然有些地方不太对劲，我需要追根究底

链接错误包括：

Error   3   error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMTD.lib(new.obj)   nafxcwd.lib
Error   4   error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj) nafxcwd.lib
Error   5   error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in LIBCMTD.lib(delete2.obj) nafxcwd.lib
Error   6   fatal error LNK1169: one or more multiply defined symbols found Tmtka.exe   1

这些通常指向各种.lib和可执行文件使用的CRT库版本（静态与动态）的不一致性。但是，所有的.lib和可执行文件都是使用“/MT”和“在静态库中使用MFC”构建的

另一个难题是，当所有的.lib和可执行文件都一致地设置为“/MD”和“在共享DLL中使用MFC”时，问题就消失了。然而，由于我们希望尽可能地继续发布静态链接（自包含）的应用程序，我们希望在继续使用“/MT”和“在静态库中使用MFC”构建的同时，找出解决方法

没有使用明确的第三方库，但是VS2008很可能链接到一些引擎盖下的库，这些库可能会动态链接到CRT或MFC，从而导致此问题。但是，为什么经过多年的成功运作，仅仅通过简单地引入这个不幸的“包含”指令，问题才会在现在显现出来

这可能是图书馆的排序问题吗

“附加依赖项”中的显式库是按顺序排列的，因此依赖于其他库的那些库会首先出现，即使MSCV链接器不会像gcc所设想的那样遭受这种试图阻止的问题。但我有一种感觉，如果这是一个间歇出现的排序问题，它可能更多地与引擎盖下依赖项的排序有关

我如何开始尝试找出这个问题？我应该使用什么工具？我尝试了depends.exe，但它似乎不想打开.lib文件（我试图确保我理解它们的依赖关系）

---

请帮助……

我也有同样的问题。当我使用MFC静态链接编译我的项目时，问题出现了，我向我的项目添加了另一个库，该库也使用MFC静态链接。将预编译头文件的C++项目选项更改为/于（<强>使用预编译页眉< /强>）确实有魔力。 尝试使用

/VERBOSE:LIB

链接器开关构建-它将告诉您链接器引入了哪些库。比较包含和不包含该标题时的输出。好吧，在#included文件中查找运算符new和delete的替换项。您不希望它们出现在调试版本中，所以请使用#ifndef Debug包装它们。@HansPassant。谢谢你，汉斯。我应该说#include是指同一个库中其他编译单元已经包含的文件。它不会重新定义任何内存分配运算符。@IgorTandetnik。谢谢你，伊戈尔。在搜索了我指向它的显式库之后，链接器在静态/MT模式下搜索下面的隐藏库列表。对于功能配置：DelayImp.lib、libcpmtd.lib、LIBCMTD.lib、OLDNAMES.lib、kernel32.lib。对于损坏的配置：DelayImp.lib、libcpmtd.lib、xcwd.lib（这个不同）、OLDNAMES.lib、nafxcwd.lib（这里是它抱怨已经定义了new和delete的地方）。找到了什么地方，但不知道如何处理这些信息。如果不包含给定的内容，则根本不会搜索xcwd或nafxcwdfile@IgorTandetnik. 继续的。。。在新位置，并表示给定的包含文件已被同一.lib中的另一个编译单元包含。不确定为什么将它包含在两个编译单元中会使链接器查找不同于仅包含在一个编译单元中的库集。