這邊之前的大多數項目都用的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
這是雖然可以通過LD_PRELOAD=/lib64/libc-2.5.so ls 加載舊的libc庫，執行一些簡單命令，但是sudo卻是怎么都進不去的。所以一定提醒大家不要在線上機器上做這種事。
5、最終的解決辦法
1）線上機器配置：
可以在用戶目錄下，建立一個文件夾$dir/Mylib64，為了下面表述方便，$dir表示該文件夾的絕對路徑。文件夾下存放開發機中/lib64/文件夾下gcc對應的庫文件，例如如下幾個：
2）開發機編譯選項：
在開發機makefile的g++編譯選項最后，添加如下選項用來指定動態庫的優先搜索路徑和動態鏈接器：
-Wl,--rpath=$dir/Mylib64 -Wl,--dynamic-linker=$dir/Mylib64/ld-linux-x86-64.so.2
其中$dir就是1）中的絕對路徑。
這樣開發機make出的可執行文件就可以在線上機器上運行了。