编译环境 VC6.0

--------------------Configuration: HY Messaging Server - Win32 Debug--------------------
Compiling...
Global.cpp
c:\program files\microsoft visual studio\vc98\mfc\include\afx.h(556) : fatal error C1001: INTERNAL COMPILER ERROR
        (compiler file 'msc1.cpp', line 1786)
         Please choose the Technical Support command on the Visual C++
         Help menu, or open the Technical Support help file for more information
Error executing cl.exe.

Global.obj - 1 error(s), 0 warning(s)

1、安装Windows Platform February SDK 2003

2、STLPORT路径正确

3、正确的配置下面的Directroy

　　符号文件（Symbol Files）是一个数据信息文件，它包含了应用程序二进制文件（比如：EXE、DLL等）调试信息，专门用来作调试之用，最终生成的可执行文件在运行时并不需要这个符号文件，但你的程序中所有的变量信息都记录在这个文件中。所以调试应用程序时，这个文件是非常重要的。用 Visual C++ 和 WinDbg 调试程序时都要用到这个文件。
　　在 Windows 系统中，符号文件以 .pdb 为扩展名，比如：每个 Windows 操作系统下有一个 GDI32.dll 文件，编译器在编译该 DLL 的时候会产生一个 GDI32.pdb 文件，一旦你拥有了这个 PDB 文件，那么便可以用它来调试并跟踪到 GDI32.dll 内部。该文件和二进制文件的编译版本密切相关，比如修改了 DLL 的输出函数，再编译该 DLL，那么原先的 PDB 文件就过时了，不能再用老的 PDB 文件来做调试工作,而必须使用最新的 PDB 文件版本。
　　Visual C++ 编译代码后会在 Debug 或者 Release 目录下生成一个 PDB 文件。一般情况下，符号文件包括以下的数据信息：

1. 全局变量（Global variables）；
2. 局部变量（Local variables）；
3. 函数名和它们的入口地址（Function names and the addresses of their entry points）；
4. FPO 数据（Frame Pointer Omission)：Frame Pointer 是一种用来在调用堆栈（Call stack）中找到下一个将要被调用的函数的数据结构源代码的行序号（Source-line numbers）；

二、如何得到和安装符号文件?

1. 先确定你的操作系统（OS）版本；
2. 到微软网站下载相应的符号文件；
3. 安装符号文件，对于符号文件的安装位置没有特贝要求，可以安装在任何目录中；
4. 设置环境变量，使得调试工具（比如：Visual C++、WinDbg、Ntsd、DrWatson 等）能找到符号文件；

安装符号文件的注意事项：

　　如果是手动安装符号文件，有一点很重要，那就是宿主机（Hostt Computer）上的符号文件必须与目标机器（Target Computer）上的 Windows 版本相匹配。
　　这里所谓的宿主机指的是运行调试会话的机器，在典型的双系统调试会话环境中，宿主机可以是连接到目标机器的任何机器。目标机器指的是发生软件组件、系统服务、应用程序或操作系统运行失败的机器。也即是需要被调试的机器，它是调试会话关注的焦点。目标机器可以近在咫尺，也可以位于完全不同的地方。有时我们也将目标机器称之为——被调试者（debuggee），那么与之对应，宿主机则可以称为调试者（debugger）。

三、在 Visual C++ 使用符号文件的方法

在 Visual C++ 6.0 中的使用方法：

1. 打开 Visual C++ 6.0 的 Workspace 文件（*.dsw）；
2. 进入 Tools 菜单，选择 Options 菜单项 (Tools->Options)；
3. 单击 Directoties 标签；
4. 在 “Show directories for”下拉列表中选择 “Executable files”；
5. 将符号文件的路径添加到 “Directories” 路径列表中；
6. 单击  OK 完成；

在 Visual C++ .NET 2003 中的使用方法：

1. 打开 Visual C++ .NET 的项目文件（*.vcproj）；
2. 在解决方案管理器中选中要使用符号文件的项目；
3. 单击右键进入项目属性对话框；
4. 选择“配置属性”中的“调试”；
5. 在与“调试”对应的“操作”选项中有一个“符号路径”，在此添加符号文件的路径即可；
6. 单击  “确定” 完成；

四、如何产生 Release 版本二进制文件对应的 PDB 文件?

在 Visual C++ 6.0 中的方法：

1. 打开 Visual C++ 6.0 的 Workspace 文件（*.dsw）；
2. 进入 Project 菜单，选择 Settings 菜单项 (Project->Settings)，打开项目设置对话框；
3. 在 “Settings for”列表中选择项目的 Release 配置；
4. 单击“C/C++”标签；
5. 在“Category”下拉列表框中选择“General”选项；
6. 在“Debug info”下拉列表框中选择调试信息格式（具体选项参见图一），在此不必禁用任何优化选项；
7. 单击“Link”标签；
8. 在“Category”下拉列表框中选择“Debug”选项；
9. 选中“Debug info”复选框，然后选择需要的链接调试类型（具体选项参见图一）；
10. 不要选择“Separate types”复选框；
11. 在“Project options”编辑框的最后添加如下指令：/opt:ref,icf；
12. 重新生成（Rebuild）项目；

在 Visual C++ .NET 2003 中的方法：

1. 打开 Visual C++ .NET 的项目文件（*.vcproj）；
2. 进入 Project 菜单，选择 Settings 菜单项 (Project->Settings)，打开项目设置对话框；
3. 在 “配置”下拉列表中选择项目的 “（活动）Release” 配置；
4. 选择“配置属性”树型节点中的“C/C++” ==〉“常规”；
5. 设置右边的“调试信息格式”选项（具体选项参见图一）；
6. 选择“配置属性”树型节点中的“链接器”==〉“调试”；
7. 设置右边的“生成程序数据库文件”（具体选项参见图一）；
8. 选择“配置属性”树型节点中的“链接器”==〉“命令行”；
9. 在“附加选项(D)”编辑框中添加如下指令：/opt:ref,icf；
10. 按“确定”退出；
11. 重新生成（Rebuild）项目；

图一

五、关于 Free Build（也称 Retail Build）和 Checked Build（也称 Debug Build）

每个基于 NT 操作系统有两种不同的程序生成模式，即：

• Free Build (或 Retail Build)
• Checked Build (或 Debug Build)

　　Free Build 生成的是最终用户版本，针对生成的二进制文件进行了彻底的优化，禁用了调试断言，并剥离了调试信息。这样一来使可执行程序文件更小，加载更快，使用的内存也更小。
　　Checked Build 生成的是测试和调试版本。它包含额外的 Free Build 所没有的错误检查，参数验证和调试信息，Checked Build 有助于隔离和跟踪可能导致不可预见的行为的问题，比如内存溢出，不正确的设备配置。虽然 Checked Build 提供了额外的保护，但与 Free Build 比较，它需要更多的内存开销和磁盘空间。由于可执行程序包含符号调试信息；调试时要执行附加的代码、参数检查和输出调试诊断信息，从而导致性能下降。

六、系统符号文件的更新方法

　　系统符号文件指 Windows 操作系统依赖的那几个重要的 DLL/SYS 和可执行文件对应的符号文件，常见的比如：gdi32.dll、Kernel32.dll、Kerberos.dll、psapi.dll、user32.dll等，使用 WinDbg 调试时，你就会发现系统符号文件(PDB)有多重要，这些文件都与本地的 OS 密切相关，比如，Windows 2000 打了SP补丁的话，那么必须更新系统符号文件才能进行相关调试，原来的符号文件与打补丁后的系统就会不匹配，怎么办呢? 可以通过网络来更新！象下面这样在 WinDbg 的 Symbols Path 里面输入路径：

SRV*D:\Symbols\websymbols*http://msdl.microsoft.com/download/symbols

（斜体部分是你在本地保存符号文件的路径）

　　如果你不是通过代理上网，那么在你用 WinDbg 打开一个被调试程序后，输入 symchk 回车，WinDbg 就会自动的连到微软的网站根据你的机器的情况更新的 PDB 文件，并将它保存在上面斜体部分指定的本地路径里，这样你就可以确保你的符号文件版本和你机器上的文件版本一致。

如果你是通过代理上网那么你需要配置 IE 的连接设置。具体方法恕不赘言。

e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(109) : error C2011: 'fd_set' : 'struct' type redefinition
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(144) : warning C4005: 'FD_SET' : macro redefinition
        e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock.h(88) : see previous definition of 'FD_SET'
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(153) : error C2011: 'timeval' : 'struct' type redefinition
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(209) : error C2011: 'hostent' : 'struct' type redefinition
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(222) : error C2011: 'netent' : 'struct' type redefinition
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(229) : error C2011: 'servent' : 'struct' type redefinition
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(241) : error C2011: 'protoent' : 'struct' type redefinition
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(397) : error C2011: 'sockaddr_in' : 'struct' type redefinition
e:\svn_now\3rdparty\microsoft\platform_sdk\2003_02_full-r2\include\winsock2.h(407) : error C2011: 'WSAData' : 'struct' type redefinition
.................................

这是由于<config-win32.h>文件中包含了

#include <windows.h>
#include <winsock2.h>

windows.h中又包含了<winsock.h>导致和winsock2.h冲突，解决方法是在include<windows.h>之前添加宏:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <winsock2.h>

因为用到了winsock2.h 所以必须加入lib文件:ws2_32.lib
再次编译，出现如下错误:

mudp.c
this compiler appears to lack vararg macros which will cause a significant degradation in efficiency
e:\libtools\openvpn-2.0.9\lzo.h(32) : fatal error C1083: Cannot open include file: 'lzo1x.h': No such file or directory
multi.c
this compiler appears to lack vararg macros which will cause a significant degradation in efficiency
e:\libtools\openvpn-2.0.9\lzo.h(32) : fatal error C1083: Cannot open include file: 'lzo1x.h': No such file or directory
ntlm.c
this compiler appears to lack vararg macros which will cause a significant degradation in efficiency
occ.c
this compiler appears to lack vararg macros which will cause a significant degradation in efficiency
e:\libtools\openvpn-2.0.9\lzo.h(32) : fatal error C1083: Cannot open include file: 'lzo1x.h': No such file or directory
openvpn.c

#ifdef USE_LZO

#ifdef LZO_HEADER_DIR
#include "lzo/lzoutil.h"
#include "lzo/lzo1x.h"
#else
#include "lzoutil.h"
#include "lzo1x.h"
#endif

因为openvpn默认配置用到了lzo压缩库，所以下载lzo压缩包:lzo-2.03,并且将lzo-2.03包中的include文件加入到工程中，注意文件目录层次，我是额外定义了lzo文件夹，将头文件全部加入进去的，因此必须加上编译选项:LZO_HEADER_DIR
另额外编译lzo lib:
    将lzo解压至C盘根目录，在命令行中跳至该目录，运行b\win32\mc120.bat，编译成功后生成lzo.lib
将生成的lzo.lib添加到工程中。
另如果不是用lzo可以修改<config_win32.h>头文件: (openssl ssl crypto也可以不使用，视具体情况)

/* Use OpenSSL crypto library */
#define USE_CRYPTO 1

/* Use LZO compression library */
#define USE_LZO 1

/* Use OpenSSL SSL library */
#define USE_SSL 1

/* Version number of package */
#define VERSION PACKAGE_VERSION

接着如果使用OpenSSL，那么首先要下载OpenSSL库，然后编译:
    a.将OpenSSL解压到C盘根目录下；
    b.在命令提示行中进入该目录，输入perl Configure VC-WIN32，检验perl是否正确安装；
    c.命令行中输入ms\do_ms；
    d.命令行中转到Microsoft Visual Studio\VC98\bin，运行vcvars32.bat以配置环境变量。
    e.命令行OpenSSL目录下，执行nmake –f ms\ntdll.mak 编译成功后，在out32dll目录下，会有四个文件libeay32.dll libeay32.lib ssleay32.dll和 ssleay32.lib,将编译成功的lzo.lib libeay32.lib ssleay32.lib添加到工程中，并将libeay32.dll ssleay32.dll拷贝到Debug目录下,并且加入openssl的头文件到工程中，和lzo库类似的过程。

另外因为VC中不识别unsigned long long int类型，需改为_int64。修改<common.h>头文件:

#ifdef USE_64_BIT_COUNTERS
//  typedef unsigned long long int counter_type;
typedef _int64 counter_type;  //qj modify

# ifdef WIN32
#  define counter_format  "%I64u"
# else
#  define counter_format  "%llu"
# endif
#else
  typedef unsigned int counter_type;
# define counter_format   "%u"
#endif

再次编译，发现错误少多了，而且全部只是一些link错误了:

Linking
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library
cryptoapi.obj : error LNK2001: unresolved external symbol __imp__CertFreeCertificateContext@4
cryptoapi.obj : error LNK2001: unresolved external symbol __imp__CryptAcquireCertificatePrivateKey@24
cryptoapi.obj : error LNK2001: unresolved external symbol __imp__CertCloseStore@8
cryptoapi.obj : error LNK2001: unresolved external symbol __imp__CertOpenStore@20
cryptoapi.obj : error LNK2001: unresolved external symbol __imp__CertFindCertificateInStore@24
route.obj : error LNK2001: unresolved external symbol _GetIpForwardTable@12
route.obj : error LNK2001: unresolved external symbol _CreateIpForwardEntry@4
route.obj : error LNK2001: unresolved external symbol _DeleteIpForwardEntry@4
tun.obj : error LNK2001: unresolved external symbol _GetAdaptersInfo@8
tun.obj : error LNK2001: unresolved external symbol _IpReleaseAddress@4
tun.obj : error LNK2001: unresolved external symbol _GetInterfaceInfo@8
tun.obj : error LNK2001: unresolved external symbol _IpRenewAddress@4
tun.obj : error LNK2001: unresolved external symbol _AddIPAddress@20
tun.obj : error LNK2001: unresolved external symbol _FlushIpNetTable@4
tun.obj : error LNK2001: unresolved external symbol _DeleteIPAddress@4
tun.obj : error LNK2001: unresolved external symbol _GetAdapterIndex@8
Debug/openvpn.exe : fatal error LNK1120: 16 unresolved externals
Error executing link.exe.

openvpn.exe - 17 error(s), 1 warning(s)

 首先解决crytoapi.obj的lnk错误，找到crytoapi.c文件中的CertFreeCertificateContext 函数，找到其声明:WinCrypt.h文件，

#include <wincrypt.h>  //需要装PLATFORM SDK
#pragma comment (lib, "crypt32.lib")

 然后解决route.obj tun.obj的问题，也是通过route.c文件中的 GetIpForwardTable等其中一个link错误的函数，找到其声明文件:IPHlpApi.h

#include <iphlpapi.h>
#pragma comment (lib, "iphlpapi.lib")

最后再次编译，OK，开始你的openvpn代码调试吧！！！

最近在VC 6.0上作業，有幾個地方都遇到一個十分惱人的錯誤。就是出現下述的錯誤： Linking... nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMTD.lib(new.obj) nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj) Debug/DCap.exe : fatal error LNK1169: one or more multiply defined symbols found

這樣的錯誤，明顯就是兩個被link到的library都提供了同名的函式。但直接ignore掉LIBCMTD.lib當然是不行的，因為它是C的library。之所以發生這個問題，是因為MFC的library和C的library相衝突，必須設定它們被link的順序，也就是先nafxcwd.lib再LIBCMTD.lib。但是這二者都是default libraries，所以要怎麼設定它們的順序呢？我找到一個解法其實挺tricky的：先把它們分別都ignore掉，再額外將它們加入。也就是說：在Link頁籤上的Ignore Libraries輸入：nafxcwd.lib libcmtd.lib，再到同一頁籤的Object/library modules輸入：nafxcwd.lib libcmtd.lib。這麼一來，加入它們的順序就成了我們所強迫設定的順序了。

需要VC7或者以上，如下

VS.Net   supports   several   macros   that   contain   the   name   of   the   current   function.  
  __FUNCDNAME__,   __FUNCSIG__,   __FUNCTION__    
  VC6   does   not   support   them.  
  用VC7.......... 

1、将DLL项目加入到主工程中间；

2、ALT+F7设置DLL属性，Link->Output file name里面的路径改为主工程目录；

3、输出DLL的Debug版本到主工程目录；

4、设置断点在DLL源文件中，F5进行调试。

Font: Fixedsys， size:16

另外：vc9 里面的Courier New字体也不错。

==============================================
备注：
装VS2008，不能有任何MS Office 2007 Beta的东西，否则会在安装“Web创作组件时”失败，因为我遇到了这个问题。

1)运行时库就是   C   run-time   library，是   C   而非   C++   语言世界的概念:取这个名字就是因为你的   C   程序运行时需要这些库中的函数.  

  2)C   语言是所谓的“小内核”语言，就其语言本身来说很小（不多的关键字，程序流程控制，数据类型等）；所以，C   语言内核开发出来之后，Dennis   Ritchie   和   Brian   Kernighan   就用   C   本身重写了   90%   以上的   UNIX   系统函数，并且把其中最常用的部分独立出来，形成头文件和对应的   LIBRARY，C   run-time   library   就是这样形成的。  
 

3)随后，随着   C   语言的流行，各个   C   编译器的生产商/个体/团体都遵循老的传统，在不同平台上都有相对应的   Standard   Library，但大部分实现都是与各个平台有关的。由于各个   C   编译器对   C   的支持和理解有很多分歧和微妙的差别，所以就有了   ANSI   C；ANSI   C   （主观意图上）详细的规定了   C   语言各个要素的具体含义和编译器实现要求，引进了新的函数声明方式，同时订立了   Standard   Library   的标准形式。所以C运行时库由编译器生产商提供。至于由其他厂商/个人/团体提供的头文件和库函数，应当称为第三方   C   运行库（Third   party   C   run-time   libraries）。  
 

4)C   run-time   library里面含有初始化代码，还有错误处理代码(例如divide   by   zero处理)。你写的程序可以没有math库，程序照样运行，只是不能处理复杂的数学运算，不过如果没有了C   run-time库，main()就不会被调用，exit()也不能被响应。因为C   run-time   library包含了C程序运行的最基本和最常用的函数。  
 

5)到了   C++   世界里，有另外一个概念:Standard   C++   Library,它包括了上面所说的   C   run-time   library   和   STL。包含   C   run-time   library   的原因很明显，C++   是   C   的超集，没有理由再重新来一个   C++   run-time   library.   VC针对C++   加入的Standard   C++   Library主要包括：LIBCP.LIB,   LIBCPMT.LIB和   MSVCPRT.LIB  
 

6)Windows环境下，VC提供的   C   run-time   library又分为动态运行时库和静态运行时库。  
  动态运行时库主要是DLL库文件msvcrt.dll(or   MSVCRTD.DLL   for   debug   build),对应的Import   library文件是MSVCRT.LIB(MSVCRTD.LIB   for   debug   build)  
  静态运行时库(release版)对应的主要文件是：  
  LIBC.LIB   (Single   thread   static   library,   retail   version)  
  LIBCMT.LIB   (Multithread   static   library,   retail   version)  

  msvcrt.dll提供几千个C函数，即使是像printf这么低级的函数都在msvcrt.dll里。其实你的程序运行时，很大一部分时间时在这些运行库里运行。在你的程序(release版)被编译时，VC会根据你的编译选项(单线程、多线程或DLL)自动将相应的运行时库文件(libc.lib,libcmt.lib或Import   library   msvcrt.lib)链接进来。

 
  编译时到底哪个C   run-time   library联入你的程序取决于编译选项：  
  /MD,   /ML,   /MT,   /LD       (Use   Run-Time   Library)  

  你可以VC中通过以下方法设置选择哪个C   run-time   library联入你的程序：  
  To   find   these   options   in   the   development   environment,   click   Settings   on   the   Project   menu.   Then   click   the   C/C++   tab,   and   click   Code   Generation   in   the   Category   box.   See   the   Use   Run-Time   Library   drop-down   box.  

  从程序可移植性考虑,如果两函数都可完成一种功能，选运行时库函数好,因为各个   C   编译器的生产商对标准C   Run-time   library提供了统一的支持. 

    大家都知道，从C/C++源程序到可执行文件要经历两个阶段:(1)编译器将源文件编译成汇编代码，然后由汇编器(assembler)翻译成机器指令(再加上其它相关信息)后输出到一个个目标文件(object file,VC的编译器编译出的目标文件默认的后缀名是.obj)中；(2)链接器(linker)将一个个的目标文件(或许还会有若干程序库)链接在一起生成一个完整的可执行文件。

    编译器编译源文件时会把源文件的全局符号(global symbol)分成强(strong)和弱(weak)两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号。比如有这么个源文件:

extern int errorno;
int buf[2] = {1,2};
int *p;

int main()
{
   return 0;
}

其中main、buf是强符号，p是弱符号，而errorno则非强非弱，因为它只是个外部变量的使用声明。

    有了强弱符号的概念，我们就可以看看链接器是如何处理与选择被多次定义过的全局符号:

规则1: 不允许强符号被多次定义(即不同的目标文件中不能有同名的强符号)；

规则2: 如果一个符号在某个目标文件中是强符号，在其它文件中都是弱符号，那么选择强符号；

规则3: 如果一个符号在所有目标文件中都是弱符号，那么选择其中任意一个；

    由上可知多个目标文件不能重复定义同名的函数与初始化了的全局变量，否则必然导致LNK2005和LNK1169两种链接错误。可是，有的时候我们并没有在自己的程序中发现这样的重定义现象，却也遇到了此种链接错误，这又是何解？嗯，问题稍微有点儿复杂，容我慢慢道来。

    众所周知，ANSI C/C++ 定义了相当多的标准函数，而它们又分布在许多不同的目标文件中，如果直接以目标文件的形式提供给程序员使用的话，就需要他们确切地知道哪个函数存在于哪个目标文件中，并且在链接时显式地指定目标文件名才能成功地生成可执行文件，显然这是一个巨大的负担。所以C语言提供了一种将多个目标文件打包成一个文件的机制，这就是静态程序库(static library)。开发者在链接时只需指定程序库的文件名，链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块，并把(且只把)它们从库中拷贝出来参与构建可执行文件。几乎所有的C/C++开发系统都会把标准函数打包成标准库提供给开发者使用(有不这么做的吗？)。

    程序库为开发者带来了方便，但同时也是某些混乱的根源。我们来看看链接器是如何解析(resolve)对程序库的引用的。
    在符号解析(symbol resolution)阶段，链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们，在此期间它要维护若干个集合:(1)集合E是将被合并到一起组成可执行文件的所有目标文件集合；(2)集合U是未解析符号(unresolved symbols，比如已经被引用但是还未被定义的符号)的集合；(3)集合D是所有之前已被加入到E的目标文件定义的符号集合。一开始，E、U、D都是空的。

(1): 对命令行中的每一个输入文件f，链接器确定它是目标文件还是库文件，如果它是目标文件，就把f加入到E，并把f中未解析的符号和已定义的符号分别加入到U、D集合中，然后处理下一个输入文件。

(2): 如果f是一个库文件，链接器会尝试把U中的所有未解析符号与f中各目标模块定义的符号进行匹配。如果某个目标模块m定义了一个U中的未解析符号，那么就把m加入到E中，并把m中未解析的符号和已定义的符号分别加入到U、D集合中。不断地对f中的所有目标模块重复这个过程直至到达一个不动点(fixed point)，此时U和D不再变化。而那些未加入到E中的f里的目标模块就被简单地丢弃，链接器继续处理下一输入文件。

(3): 如果处理过程中往D加入一个已存在的符号，或者当扫描完所有输入文件时U非空，链接器报错并停止动作。否则，它把E中的所有目标文件合并在一起生成可执行文件。

    VC带的编译器名字叫cl.exe，它有这么几个与标准程序库有关的选项: /ML、/MLd、/MT、/MTd、/MD、/MDd。这些选项告诉编译器应用程序想使用什么版本的C标准程序库。/ML(缺省选项)对应单线程静态版的标准程序库(libc.lib)；/MT对应多线程静态版标准库(libcmt.lib)，此时编译器会自动定义_MT宏；/MD对应多线程DLL版(导入库msvcrt.lib，DLL是msvcrt.dll)，编译器自动定义_MT和_DLL两个宏。后面加d的选项都会让编译器自动多定义一个_DEBUG宏，表示要使用对应标准库的调试版，因此/MLd对应调试版单线程静态标准库(libcd.lib)，/MTd对应调试版多线程静态标准库(libcmtd.lib)，/MDd对应调试版多线程DLL标准库(导入库msvcrtd.lib，DLL是msvcrtd.dll)。虽然我们的确在编译时明白无误地告诉了编译器应用程序希望使用什么版本的标准库，可是当编译器干完了活，轮到链接器开工时它又如何得知一个个目标文件到底在思念谁？为了传递相思，我们的编译器就干了点秘密的勾当。在cl编译出的目标文件中会有一个专门的区域(关心这个区域到底在文件中什么地方的朋友可以参考COFF和PE文件格式)存放一些指导链接器如何工作的信息，其中有一种就叫缺省库(default library)，这些信息指定了一个或多个库文件名，告诉链接器在扫描的时候也把它们加入到输入文件列表中(当然顺序位于在命令行中被指定的输入文件之后)。说到这里，我们先来做个小实验。写个顶顶简单的程序，然后保存为main.c :

/* main.c */
int main() { return 0; }

用下面这个命令编译main.c(什么？你从不用命令行来编译程序？这个......) :

cl /c main.c

/c是告诉cl只编译源文件，不用链接。因为/ML是缺省选项，所以上述命令也相当于: cl /c /ML main.c 。如果没什么问题的话(要出了问题才是活见鬼！当然除非你的环境变量没有设置好，这时你应该去VC的bin目录下找到vcvars32.bat文件然后运行它。)，当前目录下会出现一个main.obj文件，这就是我们可爱的目标文件。随便用一个文本编辑器打开它(是的，文本编辑器，大胆地去做别害怕)，搜索"defaultlib"字符串，通常你就会看到这样的东西: "-defaultlib:LIBC -defaultlib:OLDNAMES"。啊哈，没错，这就
是保存在目标文件中的缺省库信息。我们的目标文件显然指定了两个缺省库，一个是单线程静态版标准库libc.lib(这与/ML选项相符)，另外一个是oldnames.lib(它是为了兼容微软以前的C/C++开发系统)。

    VC的链接器是link.exe，因为main.obj保存了缺省库信息，所以可以用

link main.obj libc.lib

或者

link main.obj

来生成可执行文件main.exe，这两个命令是等价的。但是如果你用

link main.obj libcd.lib

的话，链接器会给出一个警告: "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library"，因为你显式指定的标准库版本与目标文件的缺省值不一致。通常来说，应该保证链接器合并的所有目标文件指定的缺省标准库版本一致，否则编译器一定会给出上面的警告，而LNK2005和LNK1169链接错误则有时会出现有时不会。那么这个有时到底是什么时候？呵呵，别着急，下面的一切正是为喜欢追根究底的你准备的。

    建一个源文件，就叫mylib.c，内容如下:

/* mylib.c */
＃i nclude

void foo()
{
   printf("%s","I am from mylib!\n");
}

用

cl /c /MLd mylib.c

命令编译，注意/MLd选项是指定libcd.lib为默认标准库。lib.exe是VC自带的用于将目标文件打包成程序库的命令，所以我们可以用

lib /OUT:my.lib mylib.obj

将mylib.obj打包成库，输出的库文件名是my.lib。接下来把main.c改成:

/* main.c */
void foo();

int main()
{
   foo();
   return 0;
}

用

cl /c main.c

编译，然后用

link main.obj my.lib

进行链接。这个命令能够成功地生成main.exe而不会产生LNK2005和LNK1169链接错误，你仅仅是得到了一条警告信息:"warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library"。我们根据前文所述的扫描规则来分析一下链接器此时做了些啥。

    一开始E、U、D都是空集，链接器首先扫描到main.obj，把它加入E集合，同时把未解析的foo加入U，把main加入D，而且因为main.obj的默认标准库是libc.lib，所以它被加入到当前输入文件列表的末尾。接着扫描my.lib，因为这是个库，所以会拿当前U中的所有符号(当然现在就一个foo)与my.lib中的所有目标模块(当然也只有一个mylib.obj)依次匹配，看是否有模块定义了U中的符号。结果mylib.obj确实定义了foo，于是它被加入到E，foo从U转移到D，mylib.obj引用的printf加入到U，同样地，mylib.obj指定的默认标准库是libcd.lib，它也被加到当前输入文件列表的末尾(在libc.lib的后面)。不断地在my.lib库的各模块上进行迭代以匹配U中的符号，直到U、D都不再变化。很明显，现在就已经到达了这么一个不动点，所以接着扫描下一个输入文件，就是libc.lib。链接器发现libc.lib里的printf.obj里定义有printf，于是printf从U移到D，而printf.obj被加入到E，它定义的所有符号加入到D，它里头的未解析符号加入到U。链接器还会把每个程序都要用到的一些初始化操作所在的目标模块(比如crt0.obj等)及它们所引用的模块(比如malloc.obj、free.obj等)自动加入到E中，并更新U和D以反应这个变化。事实上，标准库各目标模块里的未解析符号都可以在库内其它模块中找到定义，因此当链接器处理完libc.lib时，U一定是空的。最后处理libcd.lib，因为此时U已经为空，所以链接器会抛弃它里面的所有目标模块从而结束扫描，然后合并E中的目标模块并输出可执行文件。

    上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子，接下来你将目睹因为这种不严谨而导致的悲惨失败。

    修改mylib.c成这个样子:

＃i nclude

void foo()
{
// just a test , don"t care memory leak
   _malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );
}

其中_malloc_dbg不是ANSI C的标准库函数，它是VC标准库提供的malloc的调试版，与相关函数配套能帮助开发者抓各种内存错误。使用它一定要定义_DEBUG宏，否则预处理器会把它自动转为malloc。继续用

cl /c /MLd mylib.c
lib /OUT:my.lib mylib.obj

编译打包。当再次用

link main.obj my.lib

进行链接时，我们看到了什么？天哪，一堆的LNK2005加上个贵为"fatal error"的LNK1169垫底，当然还少不了那个LNK4098。链接器是不是疯了？不，你冤枉可怜的链接器了，我拍胸脯保证它可是一直在尽心尽责地照章办事。

    一开始E、U、D为空，链接器扫描main.obj，把它加入E，把foo加入U，把main加入D，把libc.lib加入到当前输入文件列表的末尾。接着扫描my.lib，foo从U转移到D，_malloc_dbg加入到U，libcd.lib加到当前输入文件列表的尾部。然后扫描libc.lib，这时会发现libc.lib里任何一个目标模块都没有定义_malloc_dbg(它只在调试版的标准库中存在)，所以不会有任何一个模块因为_malloc_dbg而加入E，但是每个程序都要用到的初始化模块(如crt0.obj等)及它们所引用的模块(比如malloc.obj、free.obj等)还是会自动加入到E中，同时U和D被更新以反应这个变化。当链接器处理完libc.lib时，U只剩_malloc_dbg这一个符号。最后处理libcd.lib，发现dbgheap.obj定义了_malloc_dbg，于是dbgheap.obj加入到E，它里头的未解析符号加入U，它定义的所有其它符号也加入D，这时灾难便来了。之前malloc等符号已经在D中(随着libc.lib里的malloc.obj加入E而加入的)，而dbgheap.obj又定义了包括malloc在内的许多同名符号，这引发了重定义冲突，链接器只好中断工作并报告错误。

    现在我们该知道，链接器完全没有责任，责任在我们自己的身上。是我们粗心地把缺省标准库版本不一致的目标文件(main.obj)与程序库(my.lib)链接起来，导致了大灾难。解决办法很简单，要么用/MLd选项来重编译main.c；要么用/ML选项重编译mylib.c。

    在上述例子中，我们拥有库my.lib的源代码(mylib.c)，所以可以用不同的选项重新编译这些源代码并再次打包。可如果使用的是第三方的库，它并没有提供源代码，那么我们就只有改变自己程序的编译选项来适应这些库了。但是如何知道库中目标模块指定的默认库呢？其实VC提供的一个小工具便可以完成任务，这就是dumpbin.exe。运行下面这个命令

dumpbin /DIRECTIVES my.lib

然后在输出中找那些"Linker Directives"引导的信息，你一定会发现每一处这样的信息都会包含若干个类似"-defaultlib:XXXX"这样的字符串，其中XXXX便代表目标模块指定的缺省库名。

    知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免LNK2005和LNK1169链接错误。喜欢IDE的朋友，你一样可以到 "Project属性" -> "C/C++" -> "代码生成(code generation)" -> "运行时库(run-time library)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。

终极解决办法：

在 Project/Setting/Link/General中的 Project Options: 加入 /FORCE:MULTIPLE即可。

#pragma pack(push,1)
struct RateInfoOld
  {
   time_t            ctm;                    // rate time
   int               open;                   // open price: 11987=119.87
   short             high,low,close;         // high,low,close shift from open
   double            vol;                    // volume
  };
#pragma pack(pop)

　　是的，DOS是不会说假话的，不像Windows一样总把重要的东西隐藏起来不让你看到——如果你所在的不是根目录，你将会看到“.”与“..”这两个目录——这是在资源管理器中看不到的。从DOS时代走过的朋友们大抵都明白吧，一个点代表的是当前目录，两个点代表的是上一级目录。那么我在处理信息时，就一定得把它们两个过滤出去，原因我在下面解释。do-while段的代码如下：
do
{
  if (wfd.cFileName[0] == '.')
    continue; // 过滤这两个目录
  if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
  {
    TCHAR szFile[MAX_PATH];
    if (IsRoot(lpszPath))
      wsprintf(szFile, "%s%s", lpszPath, wfd.cFileName);
    else
      wsprintf(szFile, "%s\\%s", lpszPath, wfd.cFileName);
    function(szFile); // 如果找到的是目录，则进入此目录进行递归
  }
  else
  {
    // 对文件进行操作
  }
} while (FindNextFile(hFind, &wfd));
FindClose(hFind); // 关闭查找句柄
　　现在我来解释为什么要把那两个带点的目录过滤出去。如你所见，如果找到的是目录，那么进入此目录进行递归——那么若是当前目录呢？答案很明显，如果不对其进行过滤，那么程序将进入“当前目录”进行递归。是的，如是将导致递归无休止地进行下去。
　　算法就这么多了，由于这是一个极其耗费系统资源的算法，因此你在程序中用到它的时候，最好将其放到一个单独的线程中运行，否则将会导致你的程序在查找过程中没有任何响应。
　　附：IsRoot函数源码
BOOL IsRoot(LPCTSTR lpszPath)
{
  TCHAR szRoot[4];
  wsprintf(szRoot, "%c:\\", lpszPath[0]);
  return (lstrcmp(szRoot, lpszPath) == 0);
}

解决办法，转到Stdafx.cpp，Clean, Ctrl + F7重新编译Stdafx.cpp, 然后F7编译工程即可解决。

线程本地存储 (TLS) 是一个方法，通过该方法，给定的多线程进程中的每个线程都可以分配存储线程特定数据的位置。通过 TLS API（TlsAlloc、TlsGetValue、TlsSetValue、TlsFree）方式支持动态绑定（运行时）的线程特定数据。除了现有的 API 实现，Win32 和 Visual C++ 编译器现在还支持静态绑定（加载时间）基于线程的数据。

TLS 的 API 实现

通过 Win32 API 层和编译器实现“线程本地存储”。有关详细信息，请参见 Win32 API 文档中的 TlsAlloc、TlsGetValue、TlsSetValue 和 TlsFree。

Visual C++ 编译器包括使线程本地存储操作更加自动化的关键字，而不是通过 API 层。将在下一节（TLS 的编译器实现）描述此语法。

TLS 的编译器实现

为了支持 TLS，已将新属性 thread 添加到了 C 和 C++ 语言，并由 Visual C++ 编译器支持。此属性是一个扩展存储类修饰符，如上一节中所述。使用 __declspec 关键字声明 thread 变量。例如，以下代码声明了一个整数线程局部变量，并用一个值对其进行初始化：

__declspec( thread ) int tls_i = 1;

TLS 的规则和限制
声明静态绑定线程的本地对象和变量时必须遵守下列原则： 
thread 属性只能应用于数据声明和定义。它不能用于函数声明或定义。例如，以下代码将生成一个编译器错误： 
#define Thread  __declspec( thread )
Thread void func();     // This will generate an error.
只能在具有 static 作用域的数据项上指定 thread 修饰符。包括全局数据对象（包括 static 和 extern）、本地静态对象和 C++ 类的静态数据成员。不可以用 thread 属性声明自动数据对象。以下代码将生成编译器错误： 
#define Thread  __declspec( thread )
void func1()
{
    Thread int tls_i;            // This will generate an error.
}

int func2( Thread int tls_i )    // This will generate an error.
{
    return tls_i;
}
线程本地对象的声明和定义必须全都指定 thread 属性。例如，以下代码将生成错误： 
#define Thread  __declspec( thread )
extern int tls_i;        // This will generate an error, since the
int Thread tls_i;        // declaration and definition differ.
thread 属性不能用作类型修饰符。例如，以下代码将生成一个编译器错误： 
char __declspec( thread ) *ch;        // Error
C++ 类不能使用 thread 属性。但是，可以使用 thread 属性将 C++ 类对象实例化。例如，以下代码将生成一个编译器错误： 
#define Thread  __declspec( thread )
class Thread C       // Error: classes cannot be declared Thread.
{
// Code
};
C CObject;
因为允许使用 thread 属性的 C++ 对象的声明，因此下面两个示例在语义上是等效的： 
#define Thread  __declspec( thread )
Thread class B
{
// Code
} BObject;               // OK--BObject is declared thread local.

class B
{
// Code
};
Thread B BObject;        // OK--BObject is declared thread local.
不将线程本地对象的地址视为常数，并且涉及此类地址的任何表达式都不视为常数。在标准 C 中，这种作法的效果是禁止将线程本地变量的地址用作对象或指针的初始值设定项。例如，C 编译器将以下代码标记为错误： 
#define Thread  __declspec( thread )
Thread int tls_i;
int *p = &tls_i;       //This will generate an error in C.
但是，此限制不适用于 C++。因为 C++ 允许动态初始化所有对象，因此可以用使用线程本地变量地址的表达式初始化对象。实现此操作的方式与实现线程本地对象结构的方式相同。例如，以上显示的代码在作为 C++ 源文件编译时不会生成错误。请注意：只有在其中获取地址的线程仍然存在的情况下，线程本地变量的地址才有效。 
标准 C 允许使用涉及引用自身的表达式初始化对象或变量，但只适用于非静态作用域的对象。虽然 C++ 通常允许使用涉及引用自身的表达式动态初始化对象，但是这种类型的初始化不允许用于线程本地对象。例如： 
#define Thread  __declspec( thread )
Thread int tls_i = tls_i;                // Error in C and C++ 
int j = j;                               // OK in C++, error in C
Thread int tls_i = sizeof( tls_i )       // Legal in C and C++
请注意：包含正在初始化的对象的 sizeof 表达式不建立对自身的引用且在 C 和 C++ 中都是合法的。 
C++ 不允许此类对线程数据的动态初始化，因为将来可能要对线程本地存储功能进行增强。 
如果 DLL 将任何非本地数据或对象声明为 __declspec（线程），动态加载该 DLL 时会导致保护错误。使用 LoadLibrary 加载所有 DLL 后，每当代码引用非本地 __declspec（线程）数据时，将导致系统故障。由于线程的全局变量空间是在运行时分配的，因此此空间的大小是以应用程序的需求和所有静态链接的 DLL 的需求相加为基础计算出来的。使用 LoadLibrary 时，无法扩展此空间以允许放置用 __declspec（线程）声明的线程本地变量。如果 DLL 可能是用 LoadLibrary 加载的，请在 DLL 中使用 TLS API（如 TlsAlloc）来分配 TLS。 

Home |  Overview |  How Do I |  Compiler Options

This option writes preprocessor output to a file with the same base name as the source file, but with the .I extension. It adds #line directives to the output file at the beginning and end of each included file and around lines removed by preprocessor directives that specify conditional compilation. The preprocessed listing file is identical to the original source file, except that all preprocessor directives are carried out, and macro expansions are performed.

This option suppresses compilation; CL does not produce an .OBJ file, even if the /Fo option is specified. The /P option also suppresses production of the alternate output files created by the /FA, /Fa, or /Fm option.

The /P option is similar to the /E and /EP options. Using /EP with /P suppresses placement of #line directives in the output file.

The following table summarizes the actions of the /E, /EP, and /P options.

1、一般用/P  /EP,这样就没有#line了，生成的是.i文件

2、利用这个，可以看有很多复杂宏，预编译之后的源代码，比如stl， boost等，#include的代码和相关代码，都会是被剥离后的，出现在同一个文件里，这个对于阅读代码比较有用。