debug : error LNK2019: unresolved external symbol compress referenced in function "public: int __cde

序

帮别人解决问题。
他升级了一个vc6的dll工程到vs2012, 编译不过。应该是他移植的有问题。
我先将vc6的dll工程直接用vs2015打开升级，消掉编译警告和错误后，新建了一个dll工程，移植完成，编译通过，加入svn, 将干净的版本打包给他。
他那编译不过， 在error窗口出现如下错误。

1>ClientSocket.obj : error LNK2019: unresolved external symbol compress referenced in function "public: int __cdecl CClientSocket::Send(unsigned char *,unsigned int)" (?Send@CClientSocket@@QEAAHPEAEI@Z)
1>ClientSocket.obj : error LNK2019: unresolved external symbol uncompress referenced in function "public: void __cdecl CClientSocket::OnRead(unsigned char *,unsigned long)" (?OnRead@CClientSocket@@QEAAXPEAEK@Z)

我在编译svn上的干净工程， 也编译不过了。
发现配置丢了，有可能配置文件为rcdll.VC.db(工程名称.VC.db), 因为那个文件好大个， 有几十MB。看着那么大个的临时文件，按照以前的经验，这不可能是配置文件。结果这真是配置文件， 如果将这个文件db文件删了，不归档，再打开工程，工程配置都还原成默认配置了。vs2015的工程配置文件这么大个，也是醉了。

后来实验了将近半个小时，有点明白了。原来我静态库是x86版本的， 因为配置文件被删了，工程启动后，默认的配置是x64. 将工程配置改为x86编译就过了。

总结

• 工程名称.VC.db用zip压缩后也15MB, 如果入库，肯定不值得，还是写个readme.txt, 记录一下注意事项好了, 写明干净的工程启动后， 要改那些配置值。
• 以前看错误提示，总在error窗口中看，觉得很方便。
  但是比较奇怪的错误发生时，还是要结合output看下，看看错误发生的上下文，都输出了什么提示。其实，这个错误在output窗口看，还是有很明显的提示的。

1>ClientSocket.obj : error LNK2019: unresolved external symbol compress referenced in function "public: int __cdecl CClientSocket::Send(unsigned char *,unsigned int)" (?Send@CClientSocket@@QEAAHPEAEI@Z)
1>ClientSocket.obj : error LNK2019: unresolved external symbol uncompress referenced in function "public: void __cdecl CClientSocket::OnRead(unsigned char *,unsigned long)" (?OnRead@CClientSocket@@QEAAXPEAEK@Z)
1>common\zlib\ZlibStaticLib.lib : warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64'
1>./common/zlib/ZlibStaticLib.lib : warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64'

如果看了output窗口的提示，也许分分钟就搞定了这个编译错误。
x64的工程包含了x86的静态库。

• 如果是包含的开源库，遇到编译不过时，自己重新编译一下，用自己编译的库，有可能人家编译好的工程设置和自己工程的不同，e.g. /MTD

• 自己攒下的demo还是管用，我知道错误提示的函数是zlib的函数。用自己以前作的实验srcZlibUsage.zip, 用vs2015升级后编译（工程设置和目标工程相同），没有问题，将编好的输出文件（ZlibStaticLib.lib， zlib.h， zconf.h）换到目标工程。编译再出错时，就可以排除是库的问题，排除了代码编写错误，缩小了排错范围。那就是工程配置的问题了。但是编译时，居然自己都没注意到编译的是x64的工程，真想不到。