[转]一个CMake编译问题的解决过程
2017-03-09 18:28
423 查看
问题的提出
公司的一个power-pc平台的产品,有个协议进行了修改,过程中出现了比较奇怪的情况。直接将修改后的动态库下载到设备上(原始设备是有文件系统和其他的依赖文件的,相当于部分更新应用),设备和模拟器可以正常通讯;如果将整个产品进行更新后,发现设备和模拟器通讯不正常。
实际的表象是这样的,其实是忽略了一个实际情况:老的应用使用之前的Makefile直接make编译而来,部分更新的时候,自己就是直接make生成进行的局部替换,而全部替换是使用后来自己加入的CMake的方式进行的。(这是问题的根源所在)
问题的解决
开始的时候着实折腾了好长时间,一直以为是代码的问题,所以就在代码中进行了跟踪,结果怎么都找不到问题,后来就是这份代码,直接make后,替换原有的系统的协议库,发现代码没有问题,排除了代码问题。这个问题花时间很久大概有一天时间。发现是编译方式不同导致的问题后,对两个文件进行了对比,发现使用Cmake编译出来的可执行文件是“no stripped”,以为是这个原因,后来就解决strip可执行文件的问题,在网上又是一顿狂找,最终使用“add_custom_command”定制命令的方式得到了解决,满心欢喜的看到所有应用文件都stripped了,满心以为这下可好了,但是替换以后仍然通讯异常,这个过程大概花了半天时间。
问题得不到解决很郁闷,继续对比两个文件的差异,发现即使是stripped以后,使用CMake编译出来的的文件仍然比直接使用Makefile文件make出来的文件要大不少,这些得到了一些启示,去看了下Makefile文件。通过查看Makefile和对比CMakeLists.txt文件发现,Makefile中的编译采用的宏控制,输出的是Release版本,而CMakeLists.txt中默认的输出Debug版本。找到问题所在了以后,直接又从网上找到“SET(CMAKE_BUILD_TYPE Release ON)”的方式进行了Release版本设置。
后来还发现CMakeLists.txt中的编译选项也是采用的默认方式,而Makefile中却有使用,所以干脆就直接将编译选项也直接拿过来。
SET(CMAKE_C_FLAGS "-O2 -pipe -fPIC -Wall -fmessage-length=0") SET(CMAKE_CXX_FLAGS "-O2 -pipe -fPIC -Wall -fmessage-length=0")
然后直接进行了编译,看到编译后的应用果然文件大小又小了很多,这下觉得没有问题了,进行整体更换,reboot系统,查看模拟器与设备的通讯情况,正常。ok,这一天算是没有白费,将正常后的CMakeLists.txt都更新到svn中。
我的同类文章
嵌入式开发相关(25)http://blog.csdn.net
相关文章推荐
- 一个CMake编译问题的解决过程
- 一个使用FFmpeg库读取3gp视频的例子-Android中使用FFmpeg媒体库(三).so文件编译过程问题的解决
- Ubuntu16.04+anaconda2+caffe+ssd+opencv3.1.0在编译caffe过程中的问题及解决方法 主要遇到三个问题,前两个是caffe在cmake过程中的问题,后一
- 一个博友的SQL问题解决过程
- 一个问题的解决过程。
- C++编译过程中"没有找到MFC80UD.DLL,因此这个程序未能启动.重新安装应用程序可能会修复此问题"? 的彻底解决
- 解决一个小问题-eclipse的不编译问题
- 一个编译不能通过的问题的解决
- 一个负载均衡问题的解决过程
- 终于解决了一个Win7 下 VS 编译的问题,困扰了我好几个月
- vc2005编译过程中"没有找到MFC80UD.DLL,因此这个程序未能启动.重新安装应用程序可能会修复此问题"? 的彻底解决
- 编译过程中弹出new(35) : error C2061: syntax error : identifier 'THIS_FILE'问题的原因及解决方法
- 解决了安装kchmviewer的过程中遇到的一个小问题
- gnome 2.28 编译过程中一些问题的解决
- [VC/MFC]GDI+的一个编译问题解决方案
- driverstudio生成的项目在编译过程的"ntstrsafe.h"找不到问题的解决
- 《见习小恶魔》源代码编译过程中可能出现的问题及解决方法
- 编译存储过程 等待锁定对象 时超时问题解决
- ++编译过程中"没有找到MFC80UD.DLL,因此这个程序未能启动.重新安装应用程序可能会修复此问题"? 的彻底解决
- 终于解决了一个Win7 下 VS 编译的问题,困扰了我好几个月