visual-c++ - MS VC 链接器 (link.exe) : Why no warning for 32/64 bit CPU architecture mismatch?

Question

(更新:根据 Hans 的建议，这里有一个 suggestion to improve link.exe 's behaviour，如果你在那边有账号可以投票给它。)

好吧，我是个傻瓜。一月份，我在我的电脑上安装了 Oracle，Win7 Pro 64 位。我安装了 64 位版本。昨天用MSVC Express，尝试编译链接一个小测试程序oci1.c反对oci.h和 oci.lib .

cl /nologo /c /I%ORACLE_HOME%\oci\include oci1.c
link /nologo oci1.obj /LIBPATH:%ORACLE_HOME%\oci\lib\msvc oci.lib

我的尝试一直以 LNK2019 , which means unresolved external symbol 'symbol' referenced in function 'function' 失败.有问题的符号( _OCIEnvCreate )当然是由 oci.lib 提供的。 ，所以链接器应该能够解决它。

我终于意识到它无法工作，因为我的编译器只有 32 位，而导入库是 64 位的。如果你是个傻瓜并且你不知道或不记得，那么你可以使用 dumpbin 来查看它。效用:

$ dumpbin /headers %ORACLE_HOME%\oci\lib\msvc\oci.lib | head
File Type: LIBRARY
FILE HEADER VALUES
        8664 machine (x64)

$ dumpbin /headers oci1.obj | head
File Type: COFF OBJECT
FILE HEADER VALUES
         14C machine (x86)

到现在为止还挺好。但我浪费了一些时间，并希望避免重复这种经历。
LNK2019 虽然不正确，错误消息不会引导您朝着正确的方向前进。没有警告您正在尝试链接不同 CPU 架构的二进制文件。

请注意，当您指定 X64 体系结构时，会提醒您指定 X86 二进制文件这一事实:

$ link /machine:x64 /nologo oci1.obj /LIBPATH:%ORACLE_HOME%\oci\lib\msvc oci.lib
oci1.obj : fatal error LNK1112:
Modul-Computertyp "X86" steht in Konflikt mit dem Zielcomputertyp "x64".

但是，当您显式或隐式指定 X86 架构时，没有这样的精确警告:

$ link /machine:x86 /nologo oci1.obj /LIBPATH:%ORACLE_HOME%\oci\lib\msvc oci.lib
oci1.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol
  "_OCIEnvCreate" in Funktion "_main".
oci1.exe : fatal error LNK1120: 1 nicht aufgelöste externe Verweise.

我刚刚找到 /VERBOSE switch to link.exe , 使用时暗示在我的 64 位 oci.lib 中找不到符号.

您是否可以打开其他选项以使链接过程更加，嗯，万无一失？

更新 :根据汉斯的回答，我跑了 dumpbin在 32 位导入库上，名称如下所示:

$ dumpbin /exports D:\Opt\MySQL5.5\lib\libmysql.lib
_load_defaults
_myodbc_remove_escape@8
_mysql_affected_rows@4
_mysql_autocommit@8
_mysql_change_user@16
_mysql_character_set_name@4

而我在这里处理的 64 位 OCI 导入库中的名称似乎没有修饰:

OCIXmlDbFreeXmlCtx
OCIXmlDbInitXmlCtx
ORLRconNativeInt
ORLRvalNativeInt
OraCoreIsPhysicalRawFile
OraMemAlloc

Wikipedia regarding X86 calling conventions :

When compiling for the x64 architecture in a Windows context (whether using Microsoft or non-Microsoft tools), there is only one calling convention — the one described here, so that stdcall, thiscall, cdecl, fastcall, etc., are now all one and the same.

也与 article on name mangling 相关.

现在对我来说很有意义。一个也是唯一的调用约定，因此不需要名称修改，因此根据 cdecl 没有前导下划线为 X86 编译时。

Answer 1

我认为它只是在检查二进制兼容性之前提示缺少符号。这通常会首先发生，x64 符号没有前导下划线，因为 x64 没有任何调用约定。除非您使用 Microsoft 导入库，否则它们根本不会装饰符号。

但我非常同意，首先获得兼容性错误会更有效率。不知道实现起来有多难。询问知道并可以使其工作的人，向 connect.microsoft.com 发布功能请求