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的工程,真想不到。

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页