gpt4 book ai didi

c++ - 链接器读取库但在其中找不到符号?未解析的外部符号,但仅适用于 Win32 而不是 x64

转载 作者:塔克拉玛干 更新时间:2023-11-03 00:24:58 25 4
gpt4 key购买 nike

背景

我有一个 C 天文库,我想在我的 C++ 应用程序中使用它。

我在 Win32x64 配置中在 Visual Studio 2012 Express 中构建它,并且:

  • 动态调试(.dll)
  • 动态发布(.dll)
  • 静态调试(.lib)
  • 静态发布(.lib)

...因此总共有 2 * 4 = 8 个二进制文件(不包括 *.pdb 文件等)

然后我使用 Batch Build 来构建所有配置,因为有时我需要不同的版本,我发现在一开始就完成这一切并使用一个过程比随意混合要好得多。

在我的 C++ 应用程序中,我有相同的过程,并根据名称链接到库。具体来说,在我的项目属性 Linker -> Input 字段中,我有:

SwissEphemeris_$(Platform)_$(Configuration).lib

...并且其他库目录 已正确设置。一切似乎都是对的。库文件在库目录中。

麻烦来了:

在我拥有的 8 个配置中,除了两个之外,所有配置都正确链接和构建:

  1. Win32 动态调试
  2. Win32 动态发布

对于这两种配置,相同的链接器错误:

main.obj : error LNK2019: unresolved external symbol _swe_close referenced in function _main

我尝试了一些方法来诊断或修复,但都没有用:

  1. 在新的解决方案/项目中从头开始重建库,确保 Win32x64 之间没有偏差,/MACHINE 链接器标志除外
  2. 创建一个新的解决方案/项目,除了 main() 之外什么都没有,它在 Win32 动态调试配置中调用了这个库函数 swe_close() 并链接到那个 *.lib。

错误总是一样的,如上所示。我打开了详细的链接器输出,真正让我困惑的是链接器似乎成功地找到并读取了 SwissEphemeris_Win32_DynamicDebug.lib 文件,但仍然找不到 swe_close() 符号。即使当 dumpbin.exe 显示该符号时,我需要的所有其他符号都在其中。

1>  Unused libraries:
1> E:\Data\Code\lib\SwissEphemeris\SwissEphemeris_Win32_DynamicDebug.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\user32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\gdi32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\winspool.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\comdlg32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\advapi32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\shell32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\ole32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\oleaut32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\uuid.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\odbc32.lib
1> C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\odbccp32.lib
1> E:\Programs\VS2012\VC\lib\OLDNAMES.lib
1>
1>main.obj : error LNK2019: unresolved external symbol _swe_close referenced in function _main
1>E:\Data\Code\test\Debug\test.exe : fatal error LNK1120: 1 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

挠头

有谁知道为什么链接器无法找到符号,并且用于 Win32 动态调试/发布,但对于所有 6 种其他配置都能正常工作?

为了确保库确实是为 Win32/X86 构建的,这里是库项目属性中的链接器命令行选项:

(路径与上面的路径略有不同——链接器试图找到库——因为库首先构建到这个'bin'目录,然后复制到库目录,这绝对是正在发生。)

/OUT:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.dll" 
/MANIFEST
/NXCOMPAT
/PDB:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.pdb"
/DYNAMICBASE
/IMPLIB:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.lib"
/DEBUG
/DLL
/MACHINE:X86
/SAFESEH
/PGD:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.pgd"
/SUBSYSTEM:CONSOLE
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"E:\Data\Code\libBuilders\SwissEphemeris\obj\SwissEphemeris_Win32_DynamicDebug\SwissEphemeris_Win32_DynamicDebug.dll.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO

dumpbin.exe/exports 的输出

E:\Data\Code\lib\SwissEphemeris>dumpbin /exports SwissEphemeris_Win32_DynamicDebug.dll
Microsoft (R) COFF/PE Dumper Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.


Dump of file SwissEphemeris_Win32_DynamicDebug.dll

File Type: DLL

Section contains the following exports for SwissEphemeris_Win32_DynamicDebug.dll

00000000 characteristics
528041A6 time date stamp Sun Nov 10 19:32:06 2013
0.00 version
1 ordinal base
131 number of functions
131 number of names

ordinal hint RVA name

1 0 00001195 _swe_azalt@40 = @ILT+400(_swe_azalt@40)
2 1 000011FE _swe_azalt_d@28 = @ILT+505(_swe_azalt_d@28)
3 2 000012AD _swe_azalt_rev@24 = @ILT+680(_swe_azalt_rev@24)
4 3 00001357 _swe_azalt_rev_d@20 = @ILT+850(_swe_azalt_rev_d@20)
5 4 0000126C _swe_calc@24 = @ILT+615(_swe_calc@24)
6 5 000011BD _swe_calc_d@20 = @ILT+440(_swe_calc_d@20)
7 6 0000105F _swe_calc_ut@24 = @ILT+90(_swe_calc_ut@24)
8 7 00001235 _swe_calc_ut_d@20 = @ILT+560(_swe_calc_ut_d@20)
9 8 00001389 _swe_close@0 = @ILT+900(_swe_close@0)
10 9 00001212 _swe_close_d@4 = @ILT+525(_swe_close_d@4)
...

在库头文件中为导出定义 DLL 的位置。仅定义了 MAKE_DLLPASCAL,因此此处唯一处于事件状态的语句是 #define PASCAL_CONV PASCAL#else/* 32 位 DLL */ block 。

/* DLL defines */
#ifdef MAKE_DLL
#if defined (PASCAL)
#define PASCAL_CONV PASCAL
#else
#define PASCAL_CONV
#endif
#ifdef MAKE_DLL16 /* 16bit DLL */
/* We compiled the 16bit DLL for Windows 3.x using Borland C/C++ Ver:3.x
and the -WD or -WDE compiler switch. */
#define EXP16 __export
#define EXP32
#else /* 32bit DLL */
/* To export symbols in the new DLL model of Win32, Microsoft
recommends the following approach */
#define EXP16
#define EXP32 __declspec( dllexport )
#endif
#else
#define PASCAL_CONV
#define EXP16
#define EXP32
#endif

...那么实际函数 swe_close() 声明如下所示:

ext_def( void ) swe_close(void);

他们使用了很多宏观步法,所以这解决了:

extern __declspec(dllexport) void far PASCAL swe_close();

我不熟悉 farPASCAL。这些会干扰什么吗?为什么 x64 配置可以正常工作,但 Win32 会崩溃?

最佳答案

 9    8 00001389 _swe_close@0 = @ILT+900(_swe_close@0)

DLL 中的函数名与链接器正在寻找的函数名明显不匹配。 DLL 项目已将其编译为 __stdcall 函数,您可以从 @0 修饰符看出,链接器正在寻找 __cdecl 函数。

这可能是由编译器选项/Gd 与/Gz 引起的,但这不太可能,您已经检查过了。更可能的原因是 .h 文件在其中声明了导出的函数,以便另一个项目可以 #include 它并使用 DLL。这通常是用宏汤来完成的,这样 __declspec(dllexport) 和 __declspec(dllimport) 属性就可以正确使用了。并且调用约定应始终显式声明,通常使用另一个宏。就像在 Windows SDK header 中使用 WINAPI 宏的方式一样。我会花钱买那汤的原因。

关于c++ - 链接器读取库但在其中找不到符号?未解析的外部符号,但仅适用于 Win32 而不是 x64,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19898383/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com