建一个源文件，叫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成这个样子:
　　＃include
　　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即可。