最近参与的任务是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 夜