這邊之前的大多數項目都用的java，而自己用的c++，等到快要上線的時候才發現線上機器的gcc和libc的版本都巨低，跟自己測試開發用的環境不兼容，編譯出的c++可執行文件沒法運行。解決c++程序的移植問題費了挺大周章，如下是一個具體記錄：
1、問題描述
如上所述，線上機器與開發機環境不兼容，需要做c++程序的移植。
2、表現
細節不表，總之就是程序沒法運行，找不到對應的庫。如下給出幾個跟gcc有關的錯誤提示：
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
/lib64/libc.so.6: version `GLIBC_2.7' not found
等等
3、嘗試過的方法
在開發機上使用靜態編譯可以解決大部分問題，例如thrift、cgi、redis等相關庫采用靜態編譯，線上機器就不用裝對應軟件就可以運行程序。這樣，正常的想法是把gcc相關的庫也靜態編譯進可執行文件，那麼線上機器就可以直接運行了吧，想法是好的，可惜我們嘗試了很長時間，還是以失敗告終，線上環境還是不能運行。
4、一定不要做
慘痛教訓，一定不要隨便動線上機器的libc等環境，尤其不要動內核/lib64/libc.so.6的符號鏈接（我當時頭腦發熱，將一些報錯的庫文件從開發機拷貝到線上機器，然後更改線上機器庫文件的符號鏈接，結果出了很大問題），或者草率升級線上機器的libc（也是教訓），這樣會造成系統直接down掉，因為內核跟用戶態的交互很多都依賴於libc庫，升級後與內核不兼容，則會造成基本的ls、sudo等都沒法執行。無法進入sudo權限，就無法恢復/lib64下被更改或升級的庫文件，只能重啟進入急救模式，這對運行有線上服務的機器是很致命的。如果更改了libc.so.6等的軟連接或盲目升級libc等，執行基本命令時會報類似如下錯誤：
error while loading shared libraries: /lib64/libc.so.6: ELF file OS ABI invalid
