[轉]一個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