残缺的dsw

   上班第二周了，查bug，编版本。或许是以前在杀毒软件公司工作过的原因吧，产品经理没有给我传说中的三个月“幸福的试用期”，这不，一个残缺的dsw工程扔了过来，要我尽快编译通过……当然，这种费力，费时，经常摸不到头脑还体现不出的工作成绩的活由现在的我来做岂不再合适不过了，不过我心里没有抱怨，骨头自有骨头的营养！

 

    残缺的dsw！！至于残到什么程度，那要看修理人的“医术”了。打开dsw,罗列于IDE workspace的十个工程有四家缺席。毫无疑问，第一项任务---搜捕！ctrl+F，一通忙活后一无所获，几分钟后邮件传来的负责人的解释：由于"JournTransler"被简写为"JT"，固无法找到。I  GO！！这种“残”法也太意外了吧~

 

    接下来把dsw需要的工程补齐，可以新建一个workspace重新组织所有---涉及环境设置的太多，放弃。可以用IDE单独选中添加，这种比较傻瓜化。我选了以前没用过的修改dsp文件的方法。用notepad打开dsp,一个曾经亲切的面孔呈现出来---多像Linux下的Makefile啊，在此，可以看到使用的编译器cl.exe, rc.exe,vc中设定的各个选项"/MD... ADD xxx.lib  ../.../",文件依赖关系……vc的setting dlg虽说直观，但总感觉多的零乱，用dsp一并列出，倒也简洁明了！修改就很简单了，把JournTransler替换成JT，主要涉及工程名，关联的dsp名和输出路径。

 

    编译过程比较折磨人，众多的lib冲突(如：nafxcwd.lib, libcmtd.lib)通常会在Link是表现出Link2005的错误提示。解决方法主要两点：一，保证c/c++ ---  category(code  generation) ---  Use run-time library的设置主副工程一致(比如都是 Debug MultiThread)，此处是要告诉linker使用什么版本的c标准程序库，不同的设定(如 /MT  ,/MD)常会导致对应lib(libcmt.lib,msvcrt.lib)的冲突；二，link中要正确设置lib的加载顺序(关于lib的加载顺序可以在project option末尾添加/verbose:lib，compile时便可看到 )，这是由于vc的linker会对obj文件中的强弱符号按规则(强唯一，强弱并存选强，全弱任选--这里应该是选靠前找到的)处理，crt中对new,delete,dllmain使用弱连接处理，设定lib的加载次序会nafxcwd.lib与libcmtd.lib的冲突问题，设置方法是：先忽略nafxcwd.lib与libcmtd.lib,而后再在link的libaray/module object中按序输入nafxcwd.lib，libcmtd.lib。

 

    编译中还经常出现 can't find symbol _xxxxx@xx现象，  查找(工程中过滤器记得用*.*)到其所在的lib添加到工程即可。对于can't find xxx.h之类的错误，不必将整个路径写入，c/c++  ---  category(Preprofessor)  ---  Additional included directories加入头文件所在的文件夹相对路径可解决。

 

    工程通过编译了九个，在exe没通过测试前还不能放松，修补工作还在继续……