链接错误：xxx已经在*****中定义。LIB ::究竟是什么错误？ [英] Link Error : xxx is already defined in *****.LIB :: What exactly is wrong?

问题描述

问题：

我试图使用名为 DCMTK ，它使用一些其他外部库（zlib，libtiff，libpng，libxml2，libiconv）。我已经从同一个网站下载了这些外部库（* .LIB& * .h文件）。现在，当我编译DCMTK库我收到链接错误（793错误）像这样：

 错误2错误LNK2005： __encode_pointer已在MSVCRTD.lib（MSVCR90D.dll）中定义LIBCMTD.lib dcmmkdir 
错误3错误LNK2005：__decode_pointer已在MSVCRTD.lib（MSVCR90D.dll）中定义LIBCMTD.lib dcmmkdir 
错误4错误LNK2005： __CrtSetCheckCount已在MSVCRTD.lib（MSVCR90D.dll）中定义LIBCMTD.lib dcmmkdir 
错误5错误LNK2005：__invoke_watson已在MSVCRTD.lib（MSVCR90D.dll）中定义LIBCMTD.lib dcmmkdir 
错误6错误LNK2005： __errno已在MSVCRTD.lib（MSVCR90D.dll）中定义LIBCMTD.lib dcmmkdir 
错误7错误LNK2005：__configthreadlocale已在MSVCRTD.lib（MSVCR90D.dll）中定义LIBCMTD.lib dcmmkdir 
错误8错误LNK2005： _exit已在MSVCRTD.lib（MSVCR90D.dll）中定义LIBCMTD.lib dcmmkdir 
  

这似乎是这个库的一个流行的错误，所以他们有一个FAQ条目解决这个问题，（ http://forum.dcmtk.org/viewtopic.php?t=35 ）said：

• 问题是链接器试图将不同的
  不兼容版本 Visual
  C ++运行时库到一个单一的
  二进制。


• 当你的项目的所有部分和
  链接的库不是通过Visual
  C ++中的
  相同的代码生成选项生成时，就会发生这种情况。



• 不要使用/ NODEFAULTLIB解决方法，因为可能会出现奇怪的软件
  崩溃。解决问题！默认情况下，DCMTK使用多线程或多线程
  Debug代码生成选项（
  后者用于调试模式）生成



• 请更改所有代码的项目设置，以使用这些代码
  生成选项，


• 代码生成所有DCMTK模块并重新编译。


• MFC用户请注意：DCMTK应使用多线程DLL或
  多线程DLL调试设置编译，如果
  要将库链接到
  MFC应用程序。

http://stackoverflow.com/questions/2259697/vscopengl-huge-amount-of-linker-issues-with-release-build-only 说：

似乎你的发布版本是
试图链接到
内置的调试。你可能在你的构建中有一个
破坏的依赖，（或者
，如果你的项目是
，那么你错过了重建一些东西到
的版本。）

更多技术上，你似乎是
链接项目用不同的
C运行时库设置，一个
与多线程，另一个
与多线程调试。调整
所有项目的设置为
使用与
库相同的风味，问题应该消失

问题：

到目前为止，我一直认为Name mangling是唯一可能导致链接失败的问题其未被标准化。

1. 使用调试模式 -Threaded Debug）和Release Mode（多线程）？确切地说，正在发生什么？




2. 我不知道有没有什么叫做单线程调试和单线程调试




3. 文档介绍了代码生成选项。什么代码生成选项？ WTH是哪些？




4. 文档特别警告我们不要使用/ NODEFAULTLIB解决方法。 （example / NODEFAULTLIB：msvcrt）。为什么？如何引起麻烦？究竟是什么呢？



5. 请解释文档中有关MFC用户的最后一点。因为我以后在这个项目中使用MFC。解释我们为什么要这样做？


6. 还有什么要提的吗？我的意思是类似的错误。我对Linker&其问题。

解决方案

如果您有任何类似的问题，您可以直接提及他们或某些关键字。

使用调试模式
（多线程调试）和发布
模式（多线程）？什么确切
正在发生？为什么
正是这个东西导致链接
错误？

链接器拖动库中有几个不同的原因。最简单的方法是在链接器命令行上或在链接器命令行上的链接应答文件中列出一个库。但是任何目标文件（无论是在项目中编译还是打包到库中）都可以包含链接程序选项包括请求链接的特定库。事实上，Visual C ++编译器自动嵌入与编译时使用的项目选项匹配的链接器选项。

在链接时，来自静态库文件中的所有对象文件和对象的链接器选项被组合。如果请求多个CRT库文件名，链接器会读取所有这些文件，它们会导致命名冲突，链接器不知道使用哪一个。

我想知道是否有一些名为
Single-Threaded Debug和
Single-Threaded的东西，同样会导致
同样的东西。

过去，Visual C ++的最后几个版本只发送了多线程兼容的库。

文档介绍了关于
代码生成选项的内容。什么代码
生成选项？ WTH是他们？

查看

文档特别警告我们
不使用/ NODEFAULTLIB解决方法。
（example / NODEFAULTLIB：msvcrt）。为什么？
我如何引起麻烦？

如果使用/ NODEFAULTLIB，所有存储在对象文件和库中的对象的链接器设置被忽略。你将最终没有运行时库，也可能缺少其他库。

请解释
文档中的最后一点为MFC用户。因为
我将在这个
项目中使用MFC。解释我们为什么要这样做？
如果I
不会引起什么问题。还有什么你想要
提到吗？我的意思是类似的
错误。我对Linker感兴趣
&其问题。因此，如果有任何
类似的东西，你可以提到他们
或一些关键字atleast。

MFC应用程序和MFC库必须使用相同的内存管理功能，以便由MFC分配的内存可以被应用程序释放，反之亦然。 FILE句柄和其他资源也被共享。 MFC DLL已经编译成在DLL中使用CRT，为了能够共享资源，您需要使用相同的CRT，这意味着使用DLL。

Problem:

I'm trying to use a library named DCMTK which used some other external libraries ( zlib, libtiff, libpng, libxml2, libiconv ). I've downloaded these external libraries (*.LIB & *.h files ) from the same website. Now, when I compile the DCMTK library I'm getting link errors (793 errors) like this:

Error   2   error LNK2005: __encode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll)    LIBCMTD.lib dcmmkdir 
Error   3   error LNK2005: __decode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll)    LIBCMTD.lib dcmmkdir 
Error   4   error LNK2005: __CrtSetCheckCount already defined in MSVCRTD.lib(MSVCR90D.dll)  LIBCMTD.lib dcmmkdir 
Error   5   error LNK2005: __invoke_watson already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error   6   error LNK2005: __errno already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error   7   error LNK2005: __configthreadlocale already defined in MSVCRTD.lib(MSVCR90D.dll)    LIBCMTD.lib dcmmkdir 
Error   8   error LNK2005: _exit already defined in MSVCRTD.lib(MSVCR90D.dll)   LIBCMTD.lib dcmmkdir 

Documentation:

This seems to be a popular error for this library so, they do have a FAQ entry addressing this issue which ( http://forum.dcmtk.org/viewtopic.php?t=35 ) says:

• The problem is that the linker tries to combine different, incompatible versions of the Visual C++ runtime library into a single binary.
• This happens when not all parts of your project and the libraries you link against are generated with the same code generation options in Visual C++.

• Do not use the /NODEFAULTLIB workaround, because strange software crashes may follow. Fix the problem!

• DCMTK is by default compiled with the "Multithreaded" or "Multithreaded Debug" code generation option (the latter for Debug mode).

• Either change the project settings of all of your code to use these code generation options,
• or change the code generation for all DCMTK modules and re-compile.
• MFC users beware: DCMTK should be compiled with "Multithreaded DLL" or "Multithreaded DLL Debug" settings if you want to link the libraries into an MFC application.

Solution to same problem for others:

http://stackoverflow.com/questions/2259697/vscopengl-huge-amount-of-linker-issues-with-release-build-only says:

It seems that your release build is trying to link to something that was built debug. You probably have a broken dependency in your build, (or you missed rebuilding something to release by hand if your project is normally built in pieces).

More technically, you seem to be linking projects built with different C Run Time library settings, one with "Multi-Threaded", another one with "Multi-Threaded Debug". Adjust the settings for all the projects to use the very same flavour of the library and the issue should go away

Questions:

Till now I used to think that Name mangling is the only problem that may cause linking failures if its not been standardized. Just now I knew there are other things also which can cause same effect.

1. Whats up with the "Debug Mode" (Multi-Threaded Debug) and "Release Mode" (Multi-Threaded)? What exactly is happening under the hood? Why exactly this thing is causing linking error?

2. I wonder if there is something called "Single-Threaded Debug" and "Single-Threaded" which again causes the same thing.

3. Documentation talks something about "Code Generation Options". What Code Generation Options? WTH are they?

4. Documentation specifically warns us not to use /NODEFAULTLIB workaround. (example /NODEFAULTLIB :msvcrt ). Why? How would I cause troubles? what exactly is it?

5. Please explain the last point in the documentation for MFC users. Because I'm going to use MFC later in this project. Explain Why should we do it? What troubles would it cause if I don't.
6. Anything more you'd like to mention? I mean regarding similar errors. I'm very interested in Linker & its problems. So, if there are any similar things you can mentions them or some keywords atleast.

解决方案

Whats up with the "Debug Mode" (Multi-Threaded Debug) and "Release Mode" (Multi-Threaded)? What exactly is happening under the hood? Why exactly this thing is causing linking error?

The linker drags in libraries for several different reasons. The simplest is that a library is listed on the linker command line, or in the linker answer file on the linker command line. But any object files, whether compiled in your project or packed into a library, can also contain linker options including requesting particular libraries be linked in. In fact, the Visual C++ compiler automatically embeds such linker options matching the project options you use when compiling.

At link time, all the linker options from all object files and objects in static library files get combined. If more than one CRT library filename is requested, the linker reads in all of them and them you get naming conflicts, where the linker doesn't know which one to use.

I wonder if there is something called "Single-Threaded Debug" and "Single-Threaded" which again causes the same thing.

There used to be, but the last few versions of Visual C++ have only shipped multi-thread compatible libraries.

Documentation talks something about "Code Generation Options". What Code Generation Options? WTH are they?

Look inside your project options.

Documentation specifically warns us not to use /NODEFAULTLIB workaround. (example /NODEFAULTLIB :msvcrt ). Why? How would I cause troubles? what exactly is it?

If you use /NODEFAULTLIB, all the linker settings stored within object files and objects in libraries get ignored. You'll end up with no runtime library and maybe missing other libraries. You can add them back in by hand, but it's still a big mess.

Please explain the last point in the documentation for MFC users. Because I'm going to use MFC later in this project. Explain Why should we do it? What troubles would it cause if I don't. Anything more you'd like to mention? I mean regarding similar errors. I'm very interested in Linker & its problems. So, if there are any similar things you can mentions them or some keywords atleast.

MFC applications and the MFC library have to use the same memory management functions, so that memory allocated by MFC can be freed by the application and vice-versa. FILE handles and other resources are also shared. The MFC DLLs are already compiled to use the CRT in a DLL, and in order to be able to share resources you need to use the same CRT, which means using a DLL too.

这篇关于链接错误：xxx已经在*****中定义。LIB ::究竟是什么错误？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！