如果將整個產品進行更新後，發現裝置和模擬器通訊不正常。
實際的表象是這樣的，其實是忽略了乙個實際情況：老的應用使用之前的makefile直接make編譯而來，部分更新的時候，自己就是直接make生成進行的區域性替換，而全部替換是使用後來自己加入的cmake的方式進行的。（這是問題的根源所在）
開始的時候著實折騰了好長時間，一直以為是**的問題，所以就在**中進行了跟蹤，結果怎麼都找不到問題，後來就是這份**，直接make後，替換原有的系統的協議庫，發現**沒有問題，排除了**問題。這個問題花時間很久大概有一天時間。
問題得不到解決很鬱悶，繼續對比兩個檔案的差異，發現即使是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中。
cmake編譯時遇到的問題解決
編譯cmake首先須要gcc環境，能夠執行 gcc version命令看看。假設沒有，能夠使用yum或從cd中進行安裝，此處是在虛擬機器中從cd中進行安裝。將cd鏈結到虛擬機器都會吧，此處略去，cd mkdir cd mount dev cdrom cd cd cd packages rpm ivh...
乙個sql問題的解決
表內容 2005 05 09 勝 2005 05 09 勝 2005 05 09 負 2005 05 09 負 2005 05 10 勝 2005 05 10 負 2005 05 10 負 輸出 比賽時間 勝 負 2005 05 09 2 2 2005 05 10 1 2 自己完成建表語句，插入語句...
去解決乙個問題
你自己可以選擇乙個有挑戰性的題目去攻克嘛，機器學習裡面的，不就行了。伺服器裡面也是的嘛。是的這樣我覺得比較有意思一點，是的，如果將來你真的想進入某乙個領域，你自己先主動解決乙個問題。永遠記住一點，永遠去解決問題，原先激情的你很注重這種結果，現在你踏實學習反而只注重過程不注重結果了。你自己主動去解決問...