链接时遇到LNK2001问题，怎么回事啊？

[hunmi]

新建好的一个WIN32应用程序工程，在链接的时候提示如下：
OTimer.obj : error LNK2001: unresolved external symbol _OpenTimer
SerialPort.obj : error LNK2001: unresolved external symbol _OpenUart

情况是这样的，我要在VC++的环境里调试一个纯C的程序，OTimer和SerialPort都是C文件，OpenTimer和OpenUart是C++里面定义的两个函数，分别定义如下：
void CSCommTestDlg::OpenTimer()
void CSCommTestDlg::OpenUart()

估计是声明不对，各位给支个招吧，才开始学C++，不太明白。

[hunmi]

liqian0108(乐神仙)
呵呵，就是不知道怎么在C里面调用C++中类的方法，我试了你说的办法，但是编译的时候提示CSCommTestDlg未定义，能不能再说说怎么在C里面声明一个已经定义过的类呢？
谢了谢了！

[zhNKUjw]

mark

[hunmi]

这个问题是有点菜，但是老师教育我们要不懂就问的嘛

[bm1408]

好的,即然我发的不行,那我不继续~~~
唉~
说了不在C++版混了~
(以下是我自己N年前总结的,不对的话也就这么看了)

[bm1408]

前言：
昨天脑子一热问了一个很easy的问题，结果把自己都弄糊涂了，惹来高手们的痴笑，回头想一想是个很简单的问题，却想了那么多，晕！今天做个总结吧！(:---

链接指示符(linkage directive) extern “C” 的问题：

如果我们在自己的程序中要用到其它语言所编写的函数，那么我们的调用函数就必须告诉编译器使用不同的要求。
因为函数在函数名的生成，参数的入栈，栈的清空等等方面与所使用的语言是密切相关的。
Linkage director 告诉编译器，该函数是用其他的程序设计语言编写的。Linkage director 有两种形式：
1． 单一的语句（single statement）形式：
extern “C” void exit(int );
2.复合的语句（compound statement）形式：
extern “C”
{
int printf(const char *…..);
int scanf(const char *..);
}
或：
extern “C”
{
#include <cmath>
}

这里{ }只是一个分割符，用来说明在那个链接指示符用在那些声明上，没有其它的意义了，也就是说在花括号内声明的函数是可见的了！不要胡思乱想！

extern “XX”可以告诉编译器，该函数是用其它语言来编写的，但强制这些函数采用XX语言的方式进行编译。

举个例子说吧！

C接口的方法：
C中调用C++函数：
生成一个工程叫demo
加入一个demo.c 内容如下：

int add(int a,int b );//有无都可

int main()
{
int i=add(3,2);

printf("i=%d",i);
return 0;
}
再加入一个add.cpp，（注意扩展名，强制控制台生成两种文件类型）内容如下：

int add(int a,int b)
{
return a+b;
}
如果这样编译的话，会产生下面的错误：Linking...
demo.obj : error LNK2001: unresolved external symbol _add
Debug/demo.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe
根据提示说是没有找到-add，可是我明明定义了！.
为了搞清这个这个问题，就要搞清楚到底C的函数和CPP的函数在编译之后，会变成什么样子！
C++支持重载，C中不支持，而C++怎么区分这些重载函数呢，究竟调用那下一个呢？C++会能过不同的参数来选择不同的 具有相同名称的不同的实现函数的调用。C++函数被编译以后，函数会附带一些附加的参数信息！
我们以实事说话：
在add.cpp中再加入一个同名函数实现重载
float add(float fa,float fb)
{
return fa+fb;
}
int add(int a,int b)
{
return a+b;
}
单独编译此文件没有问题！
输出一个map文件，找到add函数：
Address Publics by Value Rva+Base Lib:Object

0001:00000030 _main 00401030 f demo.obj
0001:00000080 ?add@@YAMMM@Z 00401080 f add.OBJ
0001:000000b0 ?add@@YAHHH@Z 004010b0 f add.OBJ
明白了吧！
精华都在这里了！
提示说找不到_add，原来是在C语言被编译过程中，自动加上了下画线了！
看看main就知道了！
而在C++中，函数被扩展了，?add@@YAMMM@Z，前面两个@相当于左括号，后面一个相当于右括号，中间的就是用来表示参数的了！简单吧！
两个重载函数使用了不同的参数，一个是整数，一个是浮点数，当这两个函数进行连接时，在相应的C++的连接过程中，编译器也会以编译出来的名字到对应的OBJ文件中查找。在C++编译中，会把参数的类型，名字和函数的名字组合成为一个新的函数，这样就和程序定义的函数名这相一致！

现在在看看错误提示，我们的输出文件中也找不到这个_add，所以程序不可能连接上。知道原因就解决吧！
最直接的方法就是修改C++文件的编译结果，让它产生一个对应C的函数名字，也就是按C的方法来生成对应的函数。
在C++的头文件中加入：

extern “C” 语句的作用就是把C++函数按C约定编译！
运行，OK！

Address Publics by Value Rva+Base Lib:Object

0001:00000030 _main 00401030 f demo.obj
0001:00000080 ?add@@YAMMM@Z 00401080 f add.obj
0001:000000b0 _add 004010b0 f add.obj
变了吧！

那么C++中调用C呢！
由于两者之间的关系，C++中可以说是直接调用就可以了！不过这是有条件的！
把demo.c改成：
int substract(int a,int b)
{
return a-b;
}
void hello()
{
printf("hello");
}
add.cpp改为：
void hello();
int substract(int a,int b);

int main()
{
hello();
int c=substract(4,1);
printf("c=%d",c);
return 0;
}
编译运行，出现了上次一样的错误：

加上
extern "C"
{ void hello();
int substract(int a,int b);
}

就OK了！
这是两者的map 比较：
0001:00000030 _substract 00401030 f demo.obj
0001:00000060 _hello 00401060 f demo.obj


0001:00000030 _substract 00401030 f demo.obj
0001:00000060 _hello 00401060 f demo.obj

发现是一样的！
问题在于你在add.cpp前面加入了：
void hello();
int substract(int a,int b);
这样就把两个函数编译成了C++方式，去找它的实现代码的时候，肯定出错了！
而在C调用C++的时候， int add(int a,int b );加与不加，系统只是会给出一个提示，
这或许就是C++强的地方吧！
把错误消灭在初期！

Extern “C”是唯一被保证由所有的C++实现都支持的。
以上代码在VC6。0+WINXP（倒版）下调试通过！

[thomaslw]

多看看 关于 动态链接和 静态链接 的原理和机制的书，你就能避免这些问题。

这些问题在描述COM的书中，一般都有讲。

向楼上的大哥一样~ 他讲的是静态链接的技术，要懂得了这些就能避免这些问题的发生~

[liqian0108]

把源代码发出来看看

[hunmi]

OTimer.c:
void OTimer_RP_Init()
{
OpenTimer();
}

SerialPort.c:
void InitSeriPort()
{
OpenUart();
}

SCommTestDlg.cpp:
void CSCommTestDlg::OpenTimer()
{
SetTimer(1,1,NULL); // 时间为1毫秒
}
void CSCommTestDlg::OpenUart()
{
if(m_ctrlComm.GetPortOpen())
{
m_ctrlComm.SetPortOpen(FALSE);
}
m_ctrlComm.SetCommPort(1); //选择com1
if( !m_ctrlComm.GetPortOpen())
{
m_ctrlComm.SetPortOpen(TRUE); //打开串口
}
else
{
AfxMessageBox("cannot open serial port");
}

m_ctrlComm.SetSettings("9600,n,8,1"); //波特率9600，无校验，8个数据位，1个停止位

m_ctrlComm.SetInputMode(1); //1：表示以二进制方式检取数据
m_ctrlComm.SetRThreshold(1); //参数1表示每当串口接收缓冲区中有多于或等于1个字符时将引发一个接收数据的OnComm事件
m_ctrlComm.SetInputLen(0); //设置当前接收区数据长度为0
m_ctrlComm.GetInput(); //先预读缓冲区以清除残留数据*/
}

[fiftymetre]

VC＋＋的链接错误LNK2001
>>>>学习VC＋＋时经常会遇到链接错误LNK2001，该错误非常讨厌，因为对于
编程者来说，最好改的错误莫过于编译错误，而一般说来发生连接错误时，
编译都已通过。产生连接错误的原因非常多，尤其LNK2001错误，常常使人不
明其所以然。如果不深入地学习和理解VC＋＋，要想改正连接错误LNK2001非
常困难。
>>>>初学者在学习VC＋＋的过程中，遇到的LNK2001错误的错误消息主要为：
>>>>unresolvedexternalsymbol“symbol”（不确定的外部“符号”）。
>>>>如果连接程序不能在所有的库和目标文件内找到所引用的函数、变量或
标签，将产生此错误消息。一般来说，发生错误的原因有两个：一是所引用
的函数、变量不存在、拼写不正确或者使用错误；其次可能使用了不同版本
的连接库。
>>>>以下是可能产生LNK2001错误的原因：
>>>>一．由于编码错误导致的LNK2001。
>>>>1．不相匹配的程序代码或模块定义(.DEF)文件能导致LNK2001。例如,
如果在C＋＋源文件内声明了一变量“var1”，却试图在另一文件内以变量
“VAR1”访问该变量,将发生该错误。
>>>>2．如果使用的内联函数是在.CPP文件内定义的，而不是在头文件内定
义将导致LNK2001错误。
>>>>3．调用函数时如果所用的参数类型同函数声明时的类型不符将会产生
LNK2001。
>>>>4．试图从基类的构造函数或析构函数中调用虚拟函数时将会导致LNK2001。
>>>>5．要注意函数和变量的可公用性，只有全局变量、函数是可公用的。
>>>>静态函数和静态变量具有相同的使用范围限制。当试图从文件外部访问
任何没有在该文件内声明的静态变量时将导致编译错误或LNK2001。
>>>>函数内声明的变量(局部变量)只能在该函数的范围内使用。
>>>>C＋＋的全局常量只有静态连接性能。这不同于C，如果试图在C＋＋的
多个文件内使用全局变量也会产生LNK2001错误。一种解决的方法是需要时在
头文件中加入该常量的初始化代码，并在.CPP文件中包含该头文件；另一种
方法是使用时给该变量赋以常数。
>>>>二．由于编译和链接的设置而造成的LNK2001
>>>>1．如果编译时使用的是/NOD(/NODEFAULTLIB)选项，程序所需要的运行
库和MFC库在连接时由编译器写入目标文件模块，但除非在文件中明确包含
这些库名，否则这些库不会被链接进工程文件。在这种情况下使用/NOD将导
致错误LNK2001。
>>>>2．如果没有为wWinMainCRTStartup设定程序入口，在使用Unicode和MFC
时将得到“unresolvedexternalon_WinMain@16”的LNK2001错误信息。
>>>>3．使用/MD选项编译时,既然所有的运行库都被保留在动态链接库之内，
源文件中对“func”的引用，在目标文件里即对“__imp__func”的引用。
如果试图使用静态库LIBC.LIB或LIBCMT.LIB进行连接，将在__imp__func上发
生LNK2001；如果不使用/MD选项编译，在使用MSVCxx.LIB连接时也会发生LNK2001。
>>>>4．使用/ML选项编译时，如用LIBCMT.LIB链接会在_errno上发生LNK2001。
>>>>5．当编译调试版的应用程序时，如果采用发行版模态库进行连接也会产
生LNK2001；同样，使用调试版模态库连接发行版应用程序时也会产生相同的
问题。
>>>>6．不同版本的库和编译器的混合使用也能产生问题，因为新版的库里可
能包含早先的版本没有的符号和说明。
>>>>7．在不同的模块使用内联和非内联的编译选项能够导致LNK2001。如果
创建C＋＋库时打开了函数内联（/Ob1或/Ob2)，但是在描述该函数的相应头
文件里却关闭了函数内联（没有inline关键字），这时将得到该错误信息。
为避免该问题的发生，应该在相应的头文件中用inline关键字标志内联函数。
>>>>8．不正确的/SUBSYSTEM或/ENTRY设置也能导致LNK2001。
>>>>其实，产生LNK2001的原因还有很多，以上的原因只是一部分而已，对初
学者来说这些就够理解一阵子了。但是，分析错误原因的目的是为了避免错
误的发生。LNK2001错误虽然比较困难，但是只要注意到了上述问题，还是能
够避免和予以解决的。>>>>

[yuanchuang]

Mark

[bm1408]

链接器工具错误 LNK2001无法解析的外部符号“symbol”

代码引用了链接器无法在库和对象文件中找到的内容（如函数、变量或标签）。
可能的原因

代码请求的内容不存在（例如，符号拼写错误或使用错误的大小写）。
代码请求的内容错误（使用的是混合版本的库，一些库来自产品的一个版本，而其他则来自另一个版本）。
该错误信息之后为致命错误 LNK1120。

具体原因
代码问题

如果 LNK2001 诊断文本报告 __check_commonlanguageruntime_version 是无法解析的外部符号，可参见 LNK2019 了解如何解决该问题的信息。
成员模板的定义超出了类的范围。Visual C++ 的一个限制是，成员模板的定义必须完全位于封闭类内。有关 LNK2001 和成员模板的更多信息，请参见知识库文章 Q239436。
代码或模块定义 (.def) 文件中的大小写不匹配会导致 LNK2001。例如，当在一个 C++ 源文件中将一个变量命名为 var1，并试图在另一个源文件中以 VAR1 访问该变量时。
如果项目使用函数内联，但在 .cpp 文件而非头文件中定义函数，则会导致 LNK2001。
从 C++ 程序调用 C 函数但不使用 extern "C"（这导致编译器使用 C 命名约定）会导致 LNK2001。编译器选项 /Tp 和 /Tc 使编译器将文件分别编译为 C 或 C++，与文件扩展名无关。这些选项会导致函数名与您所期望的名称不同。
试图引用没有外部链接的函数或数据会导致 LNK2001。在 C++ 中，内联函数和 const 数据具有内部链接，除非被显式指定为 extern。
缺少函数主体或变量会导致 LNK2001。如果只有函数原型或 extern 声明，编译器继续运行而不会出现任何错误，但由于没有保留函数代码或变量空间，链接器将无法解析地址调用或变量引用。
调用参数类型与函数声明中的参数类型不匹配的函数会导致 LNK2001。名称修饰将函数参数合并到最终的修饰函数名中。
错误包含的原型导致编译器需要没有提供的函数体，这样会导致 LNK2001。如果同时具有函数 F 的类实现和非类实现，请注意 C++ 范围解析规则。
在使用 C++ 时，将函数原型包含在类定义中但未能包含实现（该类的此函数的实现）会导致 LNK2001。
试图从抽象基类的构造函数或析构函数调用纯虚函数会导致 LNK2001。纯虚函数没有基类实现。
试图从包含静态变量声明的文件外部访问该静态变量会导致 LNK2001。根据定义，用 Static 修饰符声明的函数具有文件范围。静态变量具有相同的限制。
试图在函数范围外使用用该函数声明的变量（局部变量）会导致 LNK2001。
试图在多个文件中使用 C++ 全局常数会导致 LNK2001。与 C 不同，在 C++ 中全局常数具有 static 链接。若要避免此限制，可以将 const 初始化包括在头文件中，并将此头包括在 .cpp 文件中，也可以使变量成为非常数，然后使用常数引用访问它。
在生成 ATL 项目的发布版本时，指示需要 CRT 启动代码。若要修复，请执行下列操作之一：
将 _ATL_MIN_CRT 从预处理器定义列表中移除，以允许包括 CRT 启动代码。有关更多信息，请参见常规配置设置属性页。
如果可能，移除对需要 CRT 启动代码的 CRT 函数的调用，而是使用它们的 Win32 等效函数。例如，使用 lstrcmp 取代 strcmp。需要 CRT 启动代码的已知函数是一些字符串和浮点函数。
编译和链接问题

项目缺少对库 (.LIB) 或对象 (.OBJ) 文件的引用。有关更多信息，请参见用作链接器输入的 .lib 文件。
当运行时库和 MFC 库的名称包含在对象文件模块中时使用 /NOD 会导致 LNK2001。如果使用 /NOD (/NODEFAULTLIB) 选项，这些库将不会链接到项目中，除非显式包含了它们。
使用 Unicode 和 MFC 时，如果没有创建 wWinMainCRTStartup 的入口点，将在 _WinMain@16 上得到无法解析的外部对象；请使用 /ENTRY。请参见 Unicode 编程摘要。
有关更多信息，请参见下列位于 MSDN Library 中的知识库文章。在 MSDN Library 中，单击“搜索”选项卡，将文章编号或文章标题粘贴在文本框中，然后单击“列出主题”。如果按文章编号搜索，确保清除“仅搜索标题”选项。

Q125750 “PRB: Error LNK2001: '_WinMain@16': Unresolved External Symbol”
Q131204 “PRB: Wrong Project Selection Causes LNK2001 on _WinMain@16”
Q100639 “Unicode Support in the Microsoft Foundation Class Library”
Q291952 “PRB: Link Error LNK2001: Unresolved External Symbol _main”
将用 /MT 编译的代码与库 LIBC.lib 链接会在 _beginthread、_beginthreadex、_endthread 和 _endthreadex 上导致 LNK2001。
链接需要多线程库的代码（任何 MFC 代码或用 /MT 编译的代码）会在 _beginthread、_beginthreadex、_endthread 和 _endthreadex 上导致 LNK2001。有关更多信息，请参见下列知识库文章：
Q126646“PRB: Error Msg: LNK2001 on __beginthreadex and __endthreadex”
Q128641“INFO: /Mx Compiler Options and the LIBC, LIBCMT, MSVCRT Libs”
Q166504“PRB: MFC and CRT Must Match in debug/release and static/dynamic”
在用 /MD 进行编译时，因为所有的运行库现在都存放在 DLL 中，所以源中的“func”引用在对象中变为“__imp__func”引用。如果试图与静态库 LIBC.lib 或 LIBCMT.lib 链接，则将在 __imp__func 上得到 LNK2001。当不用 /MD 进行编译时，如果试图与 MSVCxx.lib 链接，则并非总是得到 LNK2001，但可能会有其他问题。
将用显式或隐式 /ML 编译的代码链接到 LIBCMT.lib 时将在 _errno 上导致 LNK2001。
在生成应用程序的调试版本时与发布模式库链接会导致 LNK2001。同样，使用 /Mxd 选项（/MLd、/MTd 或 /MDd）并/或定义 _DEBUG，然后与发布库链接将带来潜在的无法解析的外部对象（以及其他问题）。将发布模式生成与调试库链接同样会导致类似问题。
将 Microsoft 库版本和编译器产品版本混合可能会有问题。新编译器版本的库可能包含早期版本的库中没有的新符号。可能需要更改搜索路径中的目录顺序，或将它们更改为指向当前版本。
通过库文件选择下的“工具” | “选项” | “项目” | “VC++ 目录”对话框，您可以更改搜索顺序。项目的“属性页”对话框中的“链接器”文件夹可能也包含可能已过期的路径。

当安装了新的 SDK（可能在不同的位置），但没有将搜索顺序更新为指向新位置时，可能会出现此问题。通常情况下，应将新 SDK 的 include 目录和 lib 目录的路径放在默认 Visual C++ 位置的前面。另外，包含嵌入路径的项目可能仍然指向旧路径，这些路径是有效的，但对于安装到不同位置的新版本所添加的新功能已过期。

编译器供应商之间、甚至同一编译器的不同版本之间当前没有 C++ 命名标准。因此，链接用其他编译器编译的对象文件可能无法生成相同的命名方案，从而导致错误 LNK2001。
在不同模块上混合内联和非内联编译选项会导致 LNK2001。如果创建 C++ 库时打开了函数内联（/Ob1 或 /Ob2），但描述函数的相应头文件的内联是关闭的（没有 inline 关键字），将发生此错误。若要防止此问题，请在要包含到其他文件中的头文件中用 inline 定义内联函数。
如果使用 #pragma inline_depth 编译器指令，请确保具有设置为 2 或更大的值，并确保使用 /Ob1 或 /Ob2 编译器选项。
在创建纯资源 DLL 时省略 LINK 选项 /NOENTRY 将导致 LNK2001。
使用不正确的 /SUBSYSTEM 或 /ENTRY 设置会导致 LNK2001。例如，如果编写基于字符的应用程序（控制台应用程序）并指定 /SUBSYSTEM:WINDOWS，您将得到无法解析的 WinMain 外部对象。有关这些选项和入口点的更多信息，请参见 /SUBSYSTEM 和 /ENTRY 链接器选项。
创建的项目是一个托管 DLL，它包含的 Microsoft 中间语言代码没有链接到本机 C/C++ 库（如 CRT、ATL 或 MFC），而您是从使用静态变量的本机 C/C++ 库添加代码。若要修复，必须将该项目转换为混合模式。有关更多信息，请参见将 C++ 托管扩展项目从纯中间语言转换为混合模式。
导出问题

当将应用程序从 16 位移植到 32 位时，会发生 LNK2001。当前的 32 位模块定义 (.def) 文件语法要求 __cdecl、__stdcall 和 __fastcall 函数列在 EXPORTS 节中，并且不带下划线（不修饰）。这不同于 16 位语法，这些函数在 16 位语法中列出时必须带下划线（修饰）。有关更多信息，请参见模块定义文件 EXPORTS 节的说明。
在 .def 文件中列出但未找到的任何导出将导致 LNK2001。这可能是因为导出不存在、拼写错误或使用了 C++ 修饰名（.def 文件不采用修饰名）。
解释输出

如果符号无法解析，通过下列指南可获得有关函数的信息：

在 x86 平台上，用 C 编译的名称或 C++ 中的 extern "C" 名称的调用约定修饰是：
__cdecl
函数具有下划线 (_) 前缀。
__stdcall
函数具有下划线 (_) 前缀和 @ 后缀，后跟堆栈上参数的双倍字长对齐大小。
__fastcall
函数具有 @ 前缀和 @ 后缀，后跟堆栈上参数的双倍字长对齐大小。

[hunmi]

楼上几位发的东西我在GOOGLE上都找到过，试了，没用。我觉得我遇到的可能是在C里面声明C++函数的方法不正确的问题。有谁知道的，来说说看啊。

[hunmi]

比如，在C++里面声明C函数可以用extern "C" ，但是在C里面声明C++的函数又应该用什么呢？
反正extern "C++"是不行的，我试了的。:-P

[Seu_why]

mark

[liqian0108]

姑且不论搂主的代码是否能够实现，单是 OpenTimer函数的使用就出了问题。
OpenTimer函数是CSCommTestDlg类的方法，要像使用OpenTimer函数，最少要声明类实例后才能调用类方法。

void OTimer_RP_Init()
{
CSCommTestDlg dlg;
dlg.OpenTimer();
}
这样你就不会出现2001错误了

[bm1408]

楼上兄,我这里也有动态链接的东东,你要不?~~

[thomaslw]

啊~ 楼上兄,我正在努力研究这个东西,觉得确实很难, 我~~~~~要~~~~~~~~
我发短消息给你了~

谢谢~~~~~~~~~~~~

[foochow]

哈哈....好多,学习:)

[wanguodu]

直接在C里面使用类对象或类的成员函数几乎是不可能的。
但是，注意到在C++中使用用extern "C"可以将全局函数定义为纯C函数，可以利用这一点做到在C里面间接调用C++的成员函数。具体方法：

/* head.h */
#ifndef __HEAD_H
#define __HEAD_H
extern "C"
{

void OpenTimer();

}
#endif /* __HEAD_H */

/* export.cpp */
#include "head.h"

static CSCommTestDlg g_cSCommTestDlg;

extern "C" void OpenTimer()
{
g_cScommTestDlg.OpenTimer();
}

把这个cpp放到库里，C就可以调用OpenTimer了。