平台：Windows7，Visual C++ 2010
1. 引言
实验室的一个项目，用到OpenGL进行实时绘制，还用到一些其他的库，一个困扰我很久的问题就是编译时遇到的各种符号未定义，符号重定义之类的链接错误，其一般形式如下：
xxx.obj : error LNK2019: 无法解析的外部符号__xx_xxx@xx，该符号在函数 _xxx 中被引用
MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) 已经在 LIBCMTD.lib(typinfo.obj) 中定义
简单的说，这种问题一般是缺少库（library，或库的版本不对）或多个库引用的CRT（C run-time library，C语言运行库）不一致造成的。本文对这一问题做简要探讨，并用glew、freeglut库的配置作为例子。
2. 静态链接库、动态链接库、CRT、STL
我们要到一个函数，要么是需要该函数的源代码，要么是知道该函数的声明并有该函数的实现，这里的“实现”又分为静态链接库、动态链接库。在windows平台上，静态链接库对应以.lib为后缀的库文件，动态链接库对应.dll为后缀的动态链接库文件。关于静态链接库、动态链接库请参考wikipedia相应条目：
http://en.wikipedia.org/wiki/Static_library
http://en.wikipedia.org/wiki/Dynamic-link_library
我们用VC++写的程序默认编译为可执行文件（.exe），如果想发布自己的库，可以在VS的“项目属性 >> 配置属性 >> 常规 >> 配置类型”修改。这样如果以后想用这些函数就不需要引入对应.cpp文件，而只需包含带有该函数声明的头文件，并引用库文件即可——对于静态链接库，可以用“#pragma comment (lib, "xxx.lib")”指令，或在VS的“项目属性 >> 配置属性 >> 链接器 >> 输入 >> 附加依赖”中添加；对于动态链接库，可以用“__declspec(dllimport)”声明要用的函数，如果为.dll文件实现了导入库（对应的.lib文件，里面实现了函数导入，使用同静态链接库），则动态库的使用同静态库，只是程序执行时需要.dll文件。msdn上有静态库和动态库的使用教程：
http://msdn.microsoft.com/en-us/library/ms235627.aspx
http://msdn.microsoft.com/en-us/library/ms235636.aspx
简单总结，可执行文件（.exe）和库文件（.lib、.dll）都含有源代码编译出来的可执行二进制代码。静态链接和动态链接的区别在于：静态链接编译出的可执行代码体积较大，动态链接编译出的可执行代码执行时依赖对应的.dll文件。
CRT（C语言运行库）实现了C语言相关初始化代码以及实现了C函数库，C++可以看做C语言的超集，所以C++并没有“CPRT（C++运行库）”，C++也使用CRT，标准C++除CRT外还实现了STL（standard C++ library，C++标准库，注意STL是Standard Template Library的缩写，因为C++标准库主要是用模板实现的）。既然函数的“实现”至少有静态和动态之分，那CRT或STL也有不止一个版本，后文针对VC2010平台讨论这些版本。
总结，CRT是C语言函数库及初始化代码的实现，STL是C++标准库的实现，所谓“实现”就是由源代码编译出来的.lib、.dll文件等。
3. VS的编译选项
在VC2010上，CRT和STL至少分为静态和动态，静态和动态中又各自有Debug和Release版本（早期VC还有单线程和多线程之分，目前VC++中只提供多线程版本），这样CRT和STL都有至少四个版本。现在来解释引言中的符号未定义、符号重定义链接错误的可能情景，程序A中调用了函数f，函数f是在程序B中编写的，为了使用f，将程序B编译为库（而非.exe）——静态库：B.lib动态库：B.lib、B.dll，程序A为了使用f，包含头文件B.h（其中有函数f的声明）并引用B.lib：
1 #include"B.h" 2 #pragma comment (lib, "B.lib")
如果没有上面的第二句代码，则出现了符号未定义的链接错误：
main.obj : error LNK2019: 无法解析的外部符号 _f@0，该符号在函数 _main 中被引用
上面错误信息中的“_f@0”具体取决于函数调用约定的命名方式（_cdecl、_stdcall等）。
如果编译程序B时使用了动态版本的CRT而编译A时使用的是静态版本CRT（即A、B使用了不同版本的CRT），则出现了符号重定义之类的链接错误（不绝对）。
当然如果用动态链接版本的B，程序A运行时可执行文件搜索路径中必须包含B.dll，否则报告“丢失xxx.dll”之类的错误。
设置程序到底使用哪个版本的CRT可在VS的“项目属性 >> 配置属性 >> C/C++ >> 代码生成 >> 运行库”中设置，现在将几种设置对应的库文件，编译器的宏定义列在下表：
|
Option |
Preprocessor directives |
C run-time library (without iostream or standard C++ library) |
Standard C++ Library |
|
/MT |
_MT |
libcmt.lib |
LIBCPMT.LIB |
|
/MD |
_MT, _DLL |
msvcrt.lib (import library for MSVCR100.DLL) |
MSVCPRT.LIB (import library for MSVCP100.dll) |
|
/MTd |
_DEBUG, _MT |
libcmtd.lib |
LIBCPMTD.LIB |
|
/MDd |
_DEBUG, _MT, _DLL |
msvcrtd.lib (import library for MSVCR100D.DLL) |
MSVCPRTD.LIB (import library for MSVCP100D.DLL) |
其中，MT为是multi-thread的缩写，上面说了，所有这些库都是多线程的，大写D代表DLL，小写d代表debug，如/MDd下引用动态链接调试版本的库，并且编译器定义宏_DEBUG, _MT, _DLL（程序中可以用#ifdef指令来判断库版本），引用的CRT实现文件为MSVCPRTD.LIB，该文件只是导入库并没有具体的执行二进制代码，程序运行时动态链接MSVCP100D.DLL文件，STL实现文件同理。
文件名“MSVC[R,P]100[D]”中的“100”对应VC2010，VC2003、VC2005、VC2008、VC2010、VC2012分别为71、80、90、100、110，有些时候我们运行一个程序提示“丢失msvcrxxx.dll”，可以通过安装对应VS来解决，如果不想安装VS，也可通过安装“Microsoft Visual C++ 20xx [SP1] Redistributable Package”来解决。
可参考msdn的C run-time libraries条目：
http://msdn.microsoft.com/en-us/library/vstudio/abx4dbyh(v=vs.100).aspx
4. 编译glew
可到以下地址下载最新glew：
解压后打开...glew-1.10.0uildvc10glew.sln文件，可以看到有“glew_shared”和“glew_static”两个项目，从右键属性中可以看到它们分别生成动态和静态的库：
还可以看到debug和release配置下分别使用相应debug和release版本CRT：
博文写到这里，发现一个问题，“glew_static”应该使用静态版本的CRT，但从上图看到，release下是静态链接（/MT），但debug下怎么不是“/MTd”呢？（后面会进一步分析）
在使用glew是需要包含相应头文件，并链接相应库文件，将上面生成的四个版本的库文件拷贝出来：
其中文件名中的s代表static，即静态链接，d代表debug，即调试版本，不带s的是动态链接版本，不带d的是release版本，文件名可以从glew工程的配置“项目属性 >> 常规 >> 目标文件名”中看到：
然后将...glew-1.10.0includeGL下头文件拷贝出来：
将头文件所在路径添加到到VC2010项目包含目录中，有两种方法：“项目属性 >> 配置属性 >> VC++目录 >> 包含目录”或“项目属性 >> 配置属性 >> C/C++ >> 常规 >> 附加包含目录”，将库文件所在路径添加到到VC2010项目库目录中，也有两种方法：“项目属性 >> 配置属性 >> VC++目录 >> 库目录”或“项目属性 >> 配置属性 >> 链接器 >> 常规 >> 附加库目录”。
通过判断CRT版本来引用不同库（这样避免CRT版本不一致）：
1 #ifdef _DLL // dynamic link 2 #ifdef _DEBUG 3 #pragma comment (lib, "glew32d.lib") 4 #pragma comment (lib, "freeglutd.lib") 5 #else 6 #pragma comment (lib, "glew32.lib") 7 #pragma comment (lib, "freeglut.lib") 8 #endif 9 #else // static link 10 #ifdef _DEBUG 11 #pragma comment (lib, "glew32sd.lib") 12 #pragma comment (lib, "freeglutsd.lib") 13 #else 14 #pragma comment (lib, "glew32s.lib") 15 #pragma comment (lib, "freegluts.lib") 16 #endif 17 #define GLEW_STATIC 18 #define FREEGLUT_STATIC 19 #endif 20 #include "GL/glew.h" 21 #include "GL/freeglut.h"
上述代码利用编译器在不同配置（/MT、/MD、/MTd、/MDd）下内置的不同宏来判断使用的CRT版本，并引用对应版本glew和freeglut库版本。
这样配置后编译自己的程序不会再出现引言中的链接错误了，但有很多如下警告：
glew32s.lib(glew.obj) : warning LNK4099: 未找到 PDB“vc100.pdb”(使用“glew32s.lib(glew.obj)”或在“C:UsershllDesktopfluid 2014.01Releasevc100.pdb”中寻找)；正在链接对象，如同没有调试信息一样
将glew工程配置成不生成调试信息，或把调试信息直接生成到.obj文件中（而非.pdb文件）即可，“项目属性 >> 配置属性 >> C/C++ >> 常规 >> 调试信息格式”，空表示不生成调试信息，C7把调试信息直接生成到.obj文件中，默认的Zi生成.pdb文件：
接着上面说到的“glew_static”的配置问题（往上找那段绿色的话），在自己工程配置为“/MTd”时引用glew32sd.lib库程序报错如下：
1>------ 已启动生成: 项目: exampleGL, 配置: Debug_static Win32 ------
1>生成启动时间为 2014/1/15 17:42:55。
1>InitializeBuildStatus:
1> 正在对“Debug_staticexampleGL.unsuccessfulbuild”执行 Touch 任务。
1>ClCompile:
1> 所有输出均为最新。
1>ManifestResourceCompile:
1> 所有输出均为最新。
1>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) 已经在 LIBCMTD.lib(typinfo.obj) 中定义
1>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) 已经在 LIBCMTD.lib(typinfo.obj) 中定义
1>LINK : warning LNK4098: 默认库“MSVCRTD”与其他库的使用冲突；请使用 /NODEFAULTLIB:library
1>C:UsershllDesktopexampleGLDebug_staticexampleGL.exe : fatal error LNK1169: 找到一个或多个多重定义的符号
1>
1>生成失败。
1>
1>已用时间 00:00:00.38
========== 生成: 成功 0 个，失败 1 个，最新 0 个，跳过 0 个 ==========
利用上面VC2010编译配置表（往上找加粗的表），配置为“/MTd”使用的是库libcmtd.lib，而msvcrtd.lib是“/MDd”配置下使用的库，解决上述符号重定义错误的一个方法如下：
#pragma comment (linker, "/NODEFAULTLIB:MSVCRTD.lib")
但很明显，这不是漂亮的解决方法，如果我们“擅自”将“glew_static”的上述配置“/MDd”改为“/MTd” （还是往上找那段绿色的话），这个问题也会消失，看来这可能是glew发布版（1.10.0）的一个bug（除了刚分析的“glew_static” debug的配置“/MDd”改为“/MTd”，还有一处，“glew_shared” release的配置“/MT”改为“/MD”），但这正好成就了我们对本文技术分析结果的完美应用~
5. 编译freeglut
可到以下地址下载最新freeglut：
http://freeglut.sourceforge.net/
有了glew编译经验，以及自己的工程配置经验之后，freeglut的编译这里就简单些说了。
解压后打开...freeglut-2.8.1VisualStudio2010freeglut.sln文件，可以看到它的配置略有不同：
再随便打开一个CRT配置可以看到：
freeglut并没有像glew那样在CRT配置上出现小bug（还是往上找那段绿色的话）。
好了，像glew一样，用配置管理器的4个选项（debug、release、debug_static、release_static，分别对应4个CRT版本）分别编译出4个版本的库（6个文件，4个.lib，2个.dll），但freeglut并没有像glew那样将4个版本的文件分别命名用或不用s及d结尾，它的debug版和release版文件名相同，我只好自己改啦（这一改带来很多问题）：
改为：
其他类推，并将freeglut_std.h文件中如下代码：
... # pragma comment (lib, "freeglut_static.lib") ... # pragma comment (lib, "freeglut.lib") ...
修改为：
... # ifdef _DEBUG # pragma comment (lib, "freeglutsd.lib") # else # pragma comment (lib, "freegluts.lib") # endif ... # ifdef _DEBUG # pragma comment (lib, "freeglutd.lib") # else # pragma comment (lib, "freeglut.lib") # endif ...
修改依据相同，还是根据CRT的4个版本引用4个版本的.lib文件。注意，我之前在freeglut项目中只做了“目标文件名”的修改，而未做.h文件的上述修改来编译freeglut（只是将.h文件拷贝出来后才修改，这样自己项目包含的是修改后的freeglut_std.h文件，而编译freeglut用的是原版），这样的结果是，生成出来的.lib文件内部仍在引用"freeglut_static.lib"（而不是"freegluts.lib"），用二进制打开生成的.lib文件如下：
而使用修改后的freeglut_std.h文件编译freeglut结果如下：
使用未修改的freeglut_std.h文件生成"freegluts.lib" 后，自己工程包含修改后的freeglut_std.h，按说只引用"freegluts.lib"，但链接器仍报告找不到"freeglut_static.lib"文件。
另外一个类似的问题是，当编译动态链接debug版本的库时，生成文件为freeglutd.dll和freeglutd.lib（名字规则：非静态不带s，debug带d），头文件中引用"freeglutd.lib"将freeglutd.dll拷贝到VC2010自动生成的debug文件夹下（和自己工程生成的.exe文件同一文件夹），运行程序结果报告“丢失freeglut.dll”（不带我自己修改后的名字的d），编译freeglut生成的.lib和.dll文件名为freeglutd，但.lib文件内部引用的.dll文件名为freeglut（不带d），验证如下：
经过一番研究， freeglut的配置下，freeglutd.lib文件是链接器根据一个.def文件生成的（glew的导入库配置在“项目属性 >> 配置属性 >> 链接器 >> 高级 >> 导入库”）：
.def文件内容如下：
经查，第一行“LIBRARY freeglut”的含义正是“引用freeglut.dll”，将该句去掉，链接器生成的.lib文件引用的.dll文件自动和生成的.dll文件同名，问题解决：
另外值得一提的是当生成动态链接版本的.dll文件时，用到了一个资源文件，其内容如下（glew中的）：
6. 搭建OpenGL工程
工程原则：将glew和freeglut库放在工程文件夹下以避免对环境依赖、不能出现任何关于库冲突等警告（错误当然更不可以）、根据CRT的4个版本定义4个配置（debug，release，debug_static，release_static）。
将上面的glew和freeglut的编译总结在下面：
glew—
1.bug修复，“glew_static” debug的配置“/MDd”改为“/MTd”，“glew_shared” release的配置“/MT”改为“/MD”
2.不生成调试信息，“glew_static”和“glew_shared”所有配置下的“调试信息格式”改为空
3.对“glew_static” debug及release 和 “glew_shared” debug及release分别编译，得到glew32sd.lib、glew32s.lib、glew32d.lib(glew32d.dll)、glew32.lib(glew32.dll)
freeglut—
1.生成目标文件名修改，“freeglut”的“目标文件名”项原来为$(ProjectName)和$(ProjectName)_static，4个配置debug、release、debug_static、release_static分别改为$(ProjectName)d、$(ProjectName)、$(ProjectName)sd、$(ProjectName)s
2.不生成调试信息，“freeglut”所有配置下的“调试信息格式”改为空
3.freeglut_std.h文件修改如上述
4.freeglutdll.def文件删去第一行的“LIBRARY freeglut”
5.对“freeglut”的4个配置debug、release、debug_static、release_static分别编译，得到freeglutsd.lib、freegluts.lib、freeglutd.lib(freeglutd.dll)、freeglut.lib(freeglut.dll)
如下构造文件夹tool：
tool
freeglut-2.8.1
bin
freeglut.dll, freeglutd.dll
inc
GL
freeglut.h, freeglut_ext.h, freeglut_std.h, glut.h
lib
freeglut.lib, freeglutd.lib, freegluts.lib, freeglutsd.lib
glew-1.10.0
bin
glew32.dll, glew32d.dll
inc
GL
glew.h, glxew.h, wglew.h
lib
glew32.lib, glew32d.lib, glew32s.lib, glew32sd.lib
如下构造VC2010工程：
新建VS C++控制台项目，将上面tool文件夹拷贝到解决方案文件夹下
打开配置管理器，添加Debug_static（从Debug复制）和Release_static（从Release复制）配置
将Debug、Debug_static、Release、Release_static的“运行库”分别配置为：/MDd、/MTd、/MD、/MT
在VS“项目属性 >> 配置属性 >> VC++目录 >> 包含目录”所有配置下添加如下项
$(SolutionDir)toolglew-1.10.0inc
$(SolutionDir)toolfreeglut-2.8.1inc
在VS“项目属性 >> 配置属性 >> VC++目录 >> 库目录”所有配置下添加如下项
$(SolutionDir)toolglew-1.10.0lib
$(SolutionDir)toolfreeglut-2.8.1lib
添加文件gl_inc.h如下：
添加main.cpp如下：
程序运行结果截图：
考虑到方便本文的读者做实验，现将搭建的OpenGL工程exampleGL贡献出来（庸俗的代码水准让大家见笑了）：
链接: http://pan.baidu.com/s/1kTuPUQz 密码: jiky
7. 总结
在VC++上，CRT和STL有4个版本，分别对应编译选项：/MDd、/MTd、/MD、/MT；
根据编译选项的不同，开源程序编译出的库也分为多个版本（一般较全面的是4个，没有4个的可以手动添加配置），这些版本链接不同的CRT；
应根据自己程序的编译选项（用编译器预置宏来判断）链接对应的开源库，否则很有可能出现符号未定义、符号重定义的链接错误。