Questions tagged «linker»

我正在使用DCMTK库读取Dicom文件（医学图像处理中使用的图像格式。）在编译此DCMTK源代码时遇到问题。DCMTK使用其他一些外部库（zlib，tiff，libpng，libxml2，libiconv）。我知道所有库都应使用相同的代码生成选项来生成。 我已经下载了这些支持库的编译版本，这些支持库是使用“多线程DLL”运行时选项（/ MD）编译的。在DCMTK源代码的每个项目中，我确保运行时选项为“多线程DLL”（/ MD）。但是仍然出现这些错误： Error 238 error LNK2005: ___iob_func already defined in MSVCRT.lib(MSVCR100.dll) C:\dcmtk-3.5.4-src\CMakeBinaries\dcmpstat\apps\LIBCMT.lib(_file.obj) dcmp2pgm Error 239 error LNK2005: __lock_file already defined in MSVCRT.lib(MSVCR100.dll) C:\dcmtk-3.5.4-src\CMakeBinaries\dcmpstat\apps\LIBCMT.lib(_file.obj) dcmp2pgm Error 240 error LNK2005: __unlock_file already defined in MSVCRT.lib(MSVCR100.dll) C:\dcmtk-3.5.4-src\CMakeBinaries\dcmpstat\apps\LIBCMT.lib(_file.obj) dcmp2pgm Error 241 error LNK2005: __initterm_e already defined in MSVCRT.lib(MSVCR100.dll) C:\dcmtk-3.5.4-src\CMakeBinaries\dcmpstat\apps\LIBCMT.lib(crt0dat.obj) dcmp2pgm Error 242 …

76 c++  c  visual-c++  linker  msvcr100.dll 

在编译和链接期间，.exp的用途是什么？.lib和.dll有什么区别？我知道将使用.lib，而运行程序时将使用链接和.dll。但是.lib和.dll到底有什么区别？ .lib文件是否不包含来自.dll文件的功能代码？使用两个单独的文件有什么需要？ 请说清楚。

73 c  dll  linker  static-libraries 

因此，我最近在我的工作地点进行了讨论，其中我质疑使用双重包含保护而不是单个保护。我所说的双重保护如下： 头文件“ header_a.hpp”： #ifndef __HEADER_A_HPP__ #define __HEADER_A_HPP__ ... ... #endif 在头文件或源文件中的任何位置包含头文件时： #ifndef __HEADER_A_HPP__ #include "header_a.hpp" #endif 现在，我知道在头文件中使用防护是为了防止多次包含已经定义的头文件，这是常见且有据可查的。如果已经定义了宏，则编译器会将整个头文件视为“空白”，并防止重复包含。很简单。 我不理解的问题是使用#ifndef __HEADER_A_HPP__和#endif周围#include "header_a.hpp"。我的同事告诉我，这为夹杂物增加了第二层保护，但是我看不到如果第一层确实完成了工作（或做到了吗？），那么第二层是多么有用。 我能想到的唯一好处是，它彻底阻止了链接程序费心查找文件。这是否是为了缩短编译时间（这没有被提及是有好处的），还是还有其他我看不到的东西在起作用？

73 c++  macros  linker 

这个问题已经在这里有了答案： 为什么链接库的顺序有时会导致GCC错误？ （9个答案） 上个月关闭。 我正在尝试编译一个使用udis86库的程序。实际上，我正在使用库用户手册中给出的示例程序。但是在编译时会产生错误。我得到的错误是： example.c:(.text+0x7): undefined reference to 'ud_init' example.c:(.text+0x7): undefined reference to 'ud_set_input_file' . . example.c:(.text+0x7): undefined reference to 'ud_insn_asm' 我正在使用的命令是： $ gcc -ludis86 example.c -o example 按照用户手册中的指示。 显然，链接器无法链接libudis库。但是，如果我将命令更改为： $ gcc example.c -ludis86 -o example 它开始工作。因此，请有人解释第一个命令的问题是什么？

72 c  gcc  linker  ld 

这里的许多人可能都熟悉Joel Spolsky最受欢迎的博客文章之一，请问先生，我可以有一个链接器吗，他在那儿大声疾呼，希望删除对.NET框架的依赖，以便开发独立的应用程序并出售。 当时，Visual Studio开发团队的Jason Zander回答了他对该主题的看法，认为该主题有些争议-他们主要关心的是在运行时（尤其是其中）解决安全问题的能力。总的来说，少量的开销是值得的。 快进到2009年。现在有几个小组声称拥有C＃链接器。（Jason Zander甚至对自己说过，实现一个应用程序并不需要太多。）而不是.NET 1.0这么可爱的十几个meg下载，我们现在有了一个庞大的200-300 mb跨平台的完整.NET 3.5安装程序。包含适用于x86，x64和ia64的.NET版本。Microsoft减少运行时大小的建议包括： 解包可再发行组件，删除不需要的目标平台，然后重新组合在一起 使用仅为您的平台下载库的Web引导程序 使用客户端配置文件安装程序（2008年末新增），该安装程序库有限，仅适用于x86 更糟糕的是，据我了解（如果我错了，请纠正我），客户端配置文件甚至没有在Windows上注册为已安装.NET 3.5。这意味着，如果计算机上安装了多个.NET 3.5客户端应用程序，则彼此之间将不会看到对方，并且将一次又一次地重新安装运行时！ 我真的不知道微软在这里想什么。即使假设最坏的情况是针对一个目标平台（例如x64）进行安装，并且只需要包括那些库，您仍然会在应用程序上看到60 mb以上的开销。即使是最著名的.NET应用程序之一，Paint.NET，也由于庞大的.NET依赖关系而难以安装应用程序。 如果他们在分发免费应用程序时遇到问题，那么世界其他地方呢？最后，他们必须制作一个引导程序，该引导程序安装了Microsoft Installer 3.1，.NET运行时引导程序以及所有其他从属库然后才能安装自己的应用程序。 那呢 链接器。是否存在任何良好的应用程序-还是仅一种工具就可以构建C＃应用程序而无需用户安装大量的.NET运行时？ 更新：因此，看起来有两个选择： 单核细胞增多症： Mono有其自己的链接器。从下面的答案看来，它工作得很好。 。净： 异码似乎是一种可用且有效的工具。 卸载推荐使用，它是VMware推荐的。 Remotesoft还有另一个链接器。他们称其为“混淆器”。有什么想法吗？ 由Rustemsoft找到了另一个名为Skater .NET Obfuscator的文件。有人熟悉他们吗？ 还提出了微软的ILmerge ; 看起来它只执行部分任务（即合并库，而不剥离未使用的位）。 看来Mono工具正在使用；基于.NET的工具呢？他们还有其他经验吗，还是我们只需要等待Microsoft向所有人推出3.5版本？我不禁思索要推出.NET 4.0需要多长时间...

71 c#  .net  vb.net  mono  linker 

为了记录调用，我想覆盖对各种API的某些函数调用，但是我也想在将数据发送到实际函数之前对其进行操作。 例如，假设我getObjectName在源代码中使用了一个被称为数千次的函数。有时我想暂时重写此功能，因为我想更改此功能的行为以查看不同的结果。 我创建一个新的源文件，如下所示： #include <apiheader.h> const char *getObjectName (object *anObject) { if (anObject == NULL) return "(null)"; else return "name should be here"; } 我会像往常一样编译所有其他源代码，但是在与API库链接之前，我先将其与该函数链接。这工作正常，除非我显然无法在覆盖函数中调用真实函数。 有没有一种更简单的方法来“重写”一个函数而又不会得到链接/编译错误/警告？理想情况下，我希望能够仅通过编译和链接一个或两个额外的文件来覆盖该功能，而不是随意使用链接选项或更改程序的实际源代码。

71 c  function  linker  overriding 

我正在使用Eclipse-CDT在Ubuntu x64上设置一个C ++项目。我基本上是在打个招呼，并连接到商业的3rd Party库。 我已经包含了链接到它们的库的头文件，但是仍然出现链接器错误。除了明显的问题之外，这里是否还有其他可能的问题（例如，我99％确信我正在链接到正确的库）。 有没有办法确定我链接到的静态库是64位的？ 有没有一种方法可以确认该库具有我期望的类（和方法）？ Eclipse说： 建立目标：LinkProblem 调用：GCC C ++链接器 g ++ -L / home / notroot / workspace / somelib-3 / somelib / target / bin -o“ LinkProblem” ./src/LinkProblem.o -lsomelib1 -lpthread -lsomelib2 -lsomelib3 ./src/LinkProblem.o：在“ main”函数中： /home/notroot/workspace/LinkProblem/Debug/../src/LinkProblem.cpp:17：对`SomeClass :: close（）的未定义引用 ./src/LinkProblem.o：在函数“ SomeOtherClass”中： /home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:148：对`SomeClass :: SomeClass（）的未定义引用 /home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:148：对`vtable for SomeOtherClass'的未定义引用 /home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:151：对`SomeClass …

70 c++  linker  g++  eclipse-cdt 

Linux二进制文件通常动态链接到核心系统库（libc）。这样可使二进制文件的内存占用保持很小，但是依赖于最新库的二进制文件将无法在较旧的系统上运行。相反，链接到较旧库的二进制文件将在最新系统上愉快地运行。 因此，为了确保我们的应用程序在分发期间具有良好的覆盖范围，我们需要找出我们可以支持的最旧的libc并将其链接到该二进制文件。 我们应该如何确定可以链接到的最旧版本的libc？

70 linux  linker  libc