首页 > 代码库 > [转]一个CMake编译问题的解决过程
[转]一个CMake编译问题的解决过程
问题的提出
- 公司的一个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中。
我的同类文章
http://blog.csdn.net
[转]一个CMake编译问题的解决过程
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。