当前位置: 首页 > 代码生活, 流媒体学习 > 正文

遇到一个把.o文件strip后出现的奇怪问题

最近参与的任务是ONVIF的重构。在把live555组播搞完后,就正式投入ONVIF的事了。主负责ONVIF的同事已经把代码重新做了一套框架出来,大体代码已经实现了,我就把它交叉编译整合到公司架构代码上。但在编译过程中因为一个问题导致花了一天的时间才解决。

gsoap生成的代码都比较大,编译时间非常久,最大的一个文件编译差不多要20分钟。如果用-g编译,这个文件达到60MB,使用-O3优化,也有大约20MB。我无意中用file查看生成的.o文件,发现其未stripped。当strip后,发现只有区区的10MB。于是就把生成的.o文件strip掉。由于架构代码使用库的形式,在编译成静态库时一切正常,于是接着整合到主函数。但在最终链接生成二进制文件时,即出现了链接错误,典型的“unresolved reference”问题,一开始以为是extern “C”原因造成的,找了半天,编译了半天,但没什么发现。奇怪的是,使用同事的代码在PC上可以正常的——此时,尚未意识到是因为strip的原因。

多方尝试未果后,无意看到一个函数体空实现的目标文件,PC上生成的和交叉编译生成的体积不同,用UE对比发现PC编译生成的可读的字符较多,——终于想到了strip了。暂时不管其它的,把Makefile里的strip注释掉,重新编译,经过漫长的等待,终于看到生成的二进制了,问题解决。二进制文件体积有6MB,还没加什么函数实现,文件还要再精简才行。

先前的live555卡了好久的组播问题,从单线程到多线程到多进程,再到live555时间戳跟踪,花了很多时间。最终发现是发送模块的变量使用问题。我意识到多线程分头要使用2个不同的队列,也知道要不同的锁,但代码里的信号量没有修改,不同线程使用同一个信号量使得数据混乱了,而为何会导致live555的时间戳出现问题,就不得而知了。

从这些经验教训中知道,出现问题先找找自己修改过什么地方,哪些可疑的。对于多线程操作,一定要注意静态变量、全局变量等,要做好同步机制。

李迟 2016.1.15 夜

本文固定链接: http://www.latelee.org/code-life/strip-object-file-problem.html

如无特别说明,迟思堂工作室文章均为原创,转载请注明: 遇到一个把.o文件strip后出现的奇怪问题 | 迟思堂工作室

目前暂无评论

发表评论

*

快捷键:Ctrl+Enter