2

好吧，我基本上继承了一堆我被告知要修复的代码，因为它在几个月前曾经可以工作，但目前还不行。该程序本身似乎充满了链接错误，我能够修复其中的一些错误。但是，我遇到了 LNK2019 unresolved external _ imp 错误，其中主要使用的某些功能未解决。由于“ _imp”，我假设这是与从 .dll 或 .lib 文件导入有关的问题。

首先，我有三个 .lib 文件，我相信它们可以正确地导入到 VS2010 中，并且我已将平台配置为 64x。还有与 .lib 文件对应的 .dll 文件。包含这些错误函数声明的 .h 文件包含类似

ILAPI void ILAPIENTRY ilDeleteImage(const ILuint Num);

不幸的是，我猜测该定义是在我自己没有编写的 .dll 文件中定义的，所以我不确定。但由于这是在我相信我收到此错误之前有效的代码，因为链接器找不到定义而不是 def/decl 不匹配的原因。

当我将鼠标悬停在 ILAPI 上时，它指出：“ILAPI __declspec(dllimport)”我目前的猜测是程序导入 .lib 文件，而 .lib 文件使用 .dll 文件来获取函数的定义。我相信我正在导入 .lib 文件，因为编译器不再继续告诉我它找不到特定的 .lib 文件。但是我担心它可能没有连接 .dll 文件。我有些不确定。我已经打开了 .lib 文件，并且 .lib 文件包含给出错误的函数的名称。我还使用了依赖 walker 程序来查看我的 DLL 文件，它给了我以下一些错误：

错误：由于隐式依赖模块中缺少导出函数，至少一个模块具有未解析的导入。

错误：发现具有不同 CPU 类型的模块。

根据其他人的评论，我觉得我可以忽略第二个错误。但我不确定第一个错误。我也不确定这是否是问题的根本原因。它可能是也可能不是。

我还使用 VS cmd 和依赖项 walker 查看了 .lib 文件，似乎无法找到的函数的名称列在 .lib 和 .dll 之一中。

在配置方面，我在发布模式 x64 平台上运行。我在 proj -> prop -> 链接器 -> 命令行中添加了“DevIL.lib ILU.lib ILUT.lib”库函数。我还添加了链接器的路径 -> 常规 -> 附加库目录。我也尝试过弄乱输入附加依赖项，但它没有效果。.lib 和 .dll 文件也放在同一目录中。在 proj 属性配置中，我没有在任何地方提及 .dll（我应该这样做吗？我在不同的位置尝试过，但只会产生更多错误）我知道有很多关于链接 2019 错误的帖子，但我没有很好到目前为止，我在寻找我的特定问题时很幸运。我将不胜感激任何建议、评论或链接，我可以在其中找到关于为什么会发生这种情况的线索

这是来自日志的链接器命令：

这是来自构建日志本身的链接器命令：

链接：C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:PROMPT /OUT:"x64\Release\dff.exe" /VERBOSE /INCREMENTAL /NOLOGO /LIBPATH: C:\Users\Sub2\Desktop\dff\x64\Release /MANIFEST /ManifestFile:"x64\Release\dff.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG / PDB:"C:\Users\Sub2\Desktop\dff\x64\Release\dff.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"x64\Release\ dff.lib" /MACHINE:X64 x64\Release\dff.exe.embed.manifest.res x64\Release\acquisition.obj x64\Release\azmemutil.obj x64\Release\dff.obj x64\Release\fft.obj x64 \Release\FocusMeasure.obj x64\Release\ge。obj x64\Release\stdafx.obj DevIL.lib ILU.lib ILUT.lib 1>LINK：警告 LNK4075：由于“/OPT:ICF”规范而忽略“/INCREMENTAL”

    // This is from Win32's <wingdi.h> and <winnt.h>
    #if defined(__LCC__)
        #define ILAPI __stdcall
    #elif defined(_WIN32) //changed 20031221 to fix bug 840421
        #ifdef IL_STATIC_LIB
            #define ILAPI
        #else
            #ifdef _IL_BUILD_LIBRARY
                #define ILAPI __declspec(dllexport)
            #else
                #define ILAPI __declspec(dllimport)
            #endif
        #endif
    #elif __APPLE__
        #define ILAPI extern
    #else
        #define ILAPI
    #endif

还：

    #define ILAPIENTRY __stdcall

接近错误时构建日志信息：

           Found KERNEL32_NULL_THUNK_DATA
             Referenced in kernel32.lib(KERNEL32.dll)
             Loaded kernel32.lib(KERNEL32.dll)
         Searching C:\Users\Sub2\Desktop\dff\x64\Release\DevIL.lib:
         Searching C:\Users\Sub2\Desktop\dff\x64\Release\ILU.lib:
         Searching C:\Users\Sub2\Desktop\dff\x64\Release\ILUT.lib:
         Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\MSVCRT.lib:
         Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\OLDNAMES.lib:
         Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\msvcprt.lib:

     Finished searching libraries

     Finished pass 1


     Invoking CVTRES.EXE:
      /machine:amd64
      /verbose
      /out:"C:\Users\Sub2\AppData\Local\Temp\lnk92ED.tmp"
      /readonly
      "x64\Release\dff.exe.embed.manifest.res"
     Microsoft (R) Windows Resource To Object Converter Version 10.00.30319.01
     Copyright (C) Microsoft Corporation.  All rights reserved.

     adding resource. type:MANIFEST, name:1, language:0x0409, flags:0x30, size:2
 1>dff.obj : error LNK2019: unresolved external symbol __imp_iluGetImageInfo referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_iluImageParameter referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilDeleteImages referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilSaveImage referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_iluFlipImage referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_iluScale referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilTexImage referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilCopyPixels referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGetError referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilLoadImage referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilBindImage referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGenImages referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGetInteger referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilEnable referenced in function main
 1>dff.obj : error LNK2019: unresolved external symbol __imp_ilOriginFunc referenced in function main
 1>x64\Release\dff.exe : fatal error LNK1120: 16 unresolved externals
 1>Done Building Project "C:\Users\Sub2\Desktop\dff\dff.vcxproj" (rebuild target(s)) -- FAILED.

构建失败。

以防万一我也尝试过编写#define _IL_BUILD_LIBRARY 但没有效果。

4

2 回答 2

5

我在这里添加一个答案，以总结一下上述评论、可能的根本原因并找到未解决错误的解决方案。我会先说链接器往往是愚蠢的低级工具。如果目标文件中引用的符号与库不完全匹配，则构建过程会因那些未解决的错误而退出。因此，dll 库的作者和使用它的客户需要付出一些努力来确保符号一致。

根本原因

未解决的错误通常由以下原因之一引起：

  • 项目和链接的库都没有实现该符号的功能。
  • 这些库实际上确实实现了该功能，但使用了不同的参考符号。
  • 库的标头未正确预处理或修饰，从而导致#2。

打猎

基于 OP 所描述的链接的 dll 库公开了一个 C API。目前尚不清楚相关库遵循什么调用约定。dll 中的导出名称包含暗示约定的普通未修饰__cdecl函数名称。提供的相应标题，OTOH 具有如下功能：

ILAPI void ILAPIENTRY ilDeleteImage(const ILuint Num);

预处理后扩展为：

__declspec(dllimport) void __stdcall ilDeleteImage(const ILuint Num);

由此您可以得出三种可能的情况：

  1. 未解析的函数遵循__cdecl约定，并且提供的标头是错误的。
  2. 未解析的函数遵循__stdcall约定，导出的 dll 名称错误。
  3. 函数如下__stdcall，但未修饰，看起来像__cdecl在 dll 中。这表明.def文件可能已用于构建有问题的 dll。

悲伤的事态

不幸的是，win32 dll 中遵循的函数调用约定处于混乱状态。语言标准 C 或 C++ 中没有任何内容可以解决此 ABI 问题。在这里查看我的其他答案。工具链供应商可以随意装饰他们喜欢的名称，但通常对于__cdecl没有装饰或带有前缀前导_下划线的功能。

您找到的 WinAPI 函数（例如 inkernel32.dll user32.dll gdi32.dll等）也未修饰，但仍遵循__stdcall. 但是，MSVC 本身__stdcall使用带有参数总字节数的尾随 & 符号（例如ilDeleteImage@4）进行装饰，从而导致混淆。要覆盖LINK函数的装饰方式，您必须提供一个.def指定新名称别名的文件。有关更多详细信息，请参见此处。

寻找真正的约定

假设您无权访问用于构建 dll 的源代码，我可以想到两种方法来识别所使用的实际约定。

创建一个最小的测试应用程序，调用 dll 函数，就像它使用一样__cdecl，看看它是否崩溃和烧毁。这是更简单更直接的方法，您无需了解汇编即可执行此操作。

第二种方法，您执行相同的操作，但将程序集断点插入到您的测试应用程序中，并通过调试器执行单步指令来运行它。确保选择至少采用一个参数的 dll 函数。例如：

// pullin dll headers
// etc..

int main()
{
  __asm int 3;
  ilDeleteImage(0xdecafbad);
}

这将在 dll 函数调用之前中断并将控制权交还给调试器。从这里开始，在装配级别上单步执行，直到您到达ilDeleteImage's function prologue。

 ; function prologue
 push   ebp
 mov    ebp, esp
 ; function implemention
 ; more opcodes here
 ; ...

 ; function epilogue
 mov    esp, ebp
 pop    ebp
 ret    0x8

ret检查函数返回时使用的是什么形式。助记符后面的数字参数表示堆栈指针ret增加多少。esp任何大于 0 的数字都表示一个__stdcall函数。上面假设的反汇编显示了一个__stdcall在堆栈上释放 8 个字节的函数，这也暗示该函数需要 2 个参数。

于 2013-07-02T19:05:50.623 回答
0

我在使用外部静态库、QDBM 和 PCRE 构建项目时遇到了这个编译错误：

_main.obj : error LNK2001: unresolved external symbol __imp__dpversion
_main.obj : error LNK2001: unresolved external symbol __imp__regcomp

我已经正确配置了这些外部项目来构建静态库，但是我忘记在我自己的代码中定义正确的预处理器定义，它使用这些库来启用静态链接。

因此，当他们从 QDBM 和 PCRE 导入标头时，他们添加了一个__declspec(dllimport)不应该存在的（用于静态链接），因此他们试图从不存在的 DLL 中导入符号。

我将缺少的预处理器定义添加到我的构建系统中，从而修复了错误：

-DQDBM_STATIC -DPCRE_STATIC

这意味着将以下行添加到我的CMakeLists.txt文件中：

# Tell QDBM not to build itself as a DLL, because we want to link statically to it.
target_compile_definitions(qdbm PUBLIC -DQDBM_STATIC)
target_compile_definitions(lib_common PUBLIC -DPCRE_STATIC)
于 2015-12-09T21:10:54.177 回答