[转]一个CMake编译问题的解决过程

 

问题的提出

• 公司的一个power-pc平台的产品，有个协议进行了修改，过程当中出现了比较奇怪的状况。直接将修改后的动态库下载到设备上（原始设备是有文件系统和其余的依赖文件的，至关于部分更新应用），设备和模拟器能够正常通信；
• 若是将整个产品进行更新后，发现设备和模拟器通信不正常。
• 实际的表象是这样的，实际上是忽略了一个实际状况：老的应用使用以前的Makefile直接make编译而来，部分更新的时候，本身就是直接make生成进行的局部替换，而所有替换是使用后来本身加入的CMake的方式进行的。（这是问题的根源所在）

问题的解决

1. 开始的时候着实折腾了好长时间，一直觉得是代码的问题，因此就在代码中进行了跟踪，结果怎么都找不到问题，后来就是这份代码，直接make后，替换原有的系统的协议库，发现代码没有问题，排除了代码问题。这个问题花时间好久大概有一天时间。
2. 发现是编译方式不一样致使的问题后，对两个文件进行了对比，发现使用Cmake编译出来的可执行文件是“no stripped”，觉得是这个缘由，后来就解决strip可执行文件的问题，在网上又是一顿狂找，最终使用“add_custom_command”定制命令的方式获得了解决，满心欢喜的看到全部应用文件都stripped了，满心觉得这下可好了，可是替换之后仍然通信异常，这个过程大概花了半天时间。
3. 问题得不到解决很郁闷，继续对比两个文件的差别，发现即便是stripped之后，使用CMake编译出来的的文件仍然比直接使用Makefile文件make出来的文件要大很多，这些获得了一些启示，去看了下Makefile文件。经过查看Makefile和对比CMakeLists.txt文件发现,Makefile中的编译采用的宏控制，输出的是Release版本，而CMakeLists.txt中默认的输出Debug版本。找到问题所在了之后，直接又从网上找到“SET(CMAKE_BUILD_TYPE Release ON)”的方式进行了Release版本设置。
4. 后来还发现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")

   
   
5. 而后直接进行了编译，看到编译后的应用果真文件大小又小了不少，这下以为没有问题了，进行总体更换，reboot系统，查看模拟器与设备的通信状况，正常。ok，这一天算是没有白费，将正常后的CMakeLists.txt都更新到svn中。

 

 

个人同类文章

嵌入式开发相关（25）

http://blog.csdn.net