VC在编译程序时有两个习惯:
1、在从头开始编译时(即生成makefile时),将源文件名按字母排序后,依次处理;
2、一边编译一边决定需要哪些缺省库。 它的这些习惯有时会造成奇怪的编译错误,例如项目中有两个文件:
charutil.c
gbuni.cpp
其中gbnni.cpp用到了MFC库。
编译器先处理charutil.c,然后觉得需要link一个C Runtime库,根据项目设置选择了LIBCMTD.lib。
然后又处理gbnni.cpp,因为要用MFC,又决定要link nafxcwd.lib。
最后link的时候,就会出现以下冲突:
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
其实,如果先link nafxcwd.lib,再link LIBCMTD.lib,就不会产生冲突。
解决这类问题有两个办法。
1、将需要link C Runtime库的文件(charutil.c)的名字改大一些,让它排在后面。
2、在settings->link->input的Objects/library modules中设置nafxcwd.lib LIBCMTD.lib,即指定库的顺序。也可以顺利编译。
总结一下:在发生缺省库冲突时,可以通过手工设置缺省库的顺序来解决,正确的顺序应该是:
MFC库、CRT动态链接版本的导入库、CRT静态库。
CRT是C RunTime库的缩写。
关于link过程更详细的介绍可以参见http://blog.csdn.net/soloist/archive/2005/09/30/493238.aspx,我从这篇文章中受益良多,感谢作者soloist。
本文转自
http://blog.csdn.net/fmddlmyy/archive/2005/04/28/367333.aspx
1、在从头开始编译时(即生成makefile时),将源文件名按字母排序后,依次处理;
2、一边编译一边决定需要哪些缺省库。 它的这些习惯有时会造成奇怪的编译错误,例如项目中有两个文件:
charutil.c
gbuni.cpp
其中gbnni.cpp用到了MFC库。
编译器先处理charutil.c,然后觉得需要link一个C Runtime库,根据项目设置选择了LIBCMTD.lib。
然后又处理gbnni.cpp,因为要用MFC,又决定要link nafxcwd.lib。
最后link的时候,就会出现以下冲突:
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
其实,如果先link nafxcwd.lib,再link LIBCMTD.lib,就不会产生冲突。
解决这类问题有两个办法。
1、将需要link C Runtime库的文件(charutil.c)的名字改大一些,让它排在后面。
2、在settings->link->input的Objects/library modules中设置nafxcwd.lib LIBCMTD.lib,即指定库的顺序。也可以顺利编译。
总结一下:在发生缺省库冲突时,可以通过手工设置缺省库的顺序来解决,正确的顺序应该是:
MFC库、CRT动态链接版本的导入库、CRT静态库。
CRT是C RunTime库的缩写。
关于link过程更详细的介绍可以参见http://blog.csdn.net/soloist/archive/2005/09/30/493238.aspx,我从这篇文章中受益良多,感谢作者soloist。
本文转自
http://blog.csdn.net/fmddlmyy/archive/2005/04/28/367333.aspx