Linux開發中,新舊版本不同的系統會遇到的一個很大問題是--兼容性。一般情況是舊系統編譯的程序可以在新系統中運行，但是反過來新系統中編譯的程序在舊系統中就不行了。
最明顯的現象是高版本編譯的程序在低版本系統中出現錯誤: /lib64/libc.so.6: version `GLIBC_2.7' not found 當然這個版本號碼不一定是本文中的7 還有14也是個新版本，這要看你編譯時的系統的版本了。
出現這個問題後我們首先需要確定是那些函數在當前系統(低版本的)中找不到，此處使用 objdump 命令,此處假設我們的應用程序名稱爲app，則
objdump -T app | grep GLIBC_2.7 （這個號碼是上面出錯的號碼），得到了如下結果
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.7 __isoc99_sscanf
然後根據這個我們再看看當前系統有這個函數的哪個版本，命令如下
objdump -T /lib64/libc.so.6 | grep sscanf 得到如下結果
0000003e3685f050 g DF .text 0000000000000090 GLIBC_2.2.5 _IO_sscanf
0000003e3685f050 g DF .text 0000000000000090 GLIBC_2.2.5 sscanf
0000003e36863d10 w DF .text 000000000000009d GLIBC_2.2.5 vsscanf
0000003e36863d10 w DF .text 000000000000009d GLIBC_2.2.5 __vsscanf
也就是說關於sscanf這個函數當前(低版本)系統只有這幾個函數可用，所以我們的軟件想在該系統上運行也只能用這些函數，再高級的那就不支持了。
我們再去編譯程序的環境下看看它關於這個函數都有那些
objdump -T /lib64/libc.so.6 | grep sscanf
000000335c264ca0 g DF .text 0000000000000090 GLIBC_2.7 __isoc99_sscanf
000000335c264d30 g DF .text 00000000000000a2 GLIBC_2.7 __isoc99_vsscanf
000000335c2639a0 g DF .text 0000000000000090 GLIBC_2.2.5 _IO_sscanf
000000335c2639a0 g DF .text 0000000000000090 GLIBC_2.2.5 sscanf
000000335c269950 w DF .text 000000000000009d GLIBC_2.2.5 vsscanf
000000335c269950 w DF .text 000000000000009d GLIBC_2.2.5 __vsscanf
很明顯，前兩行正是高版本系統多出來的，也是低版本系統中沒有的，也恰恰是程序需要的，
此時，我們在高版本編譯時，要指定對於sscanf這個函數就使用GLIBC_2.2.5 sscanf 這個版本就行了，高低版本中都有該函數，而且我們使用的更多的是sscanf的基礎功能至於高版本的那個特性，其實我們真的沒有用到。
所以我們找到我們程序中包含sscanf的調用的文件，在其前面寫上如下彙編
__asm__(".symver __isoc99_sscanf,sscanf@GLIBC_2.2.5");
意思是遇到__isoc99_sscanf 直接變成sscanf@GLIBC_2.2.5就可以了。
如果有sscanf的地方都寫這個還太麻煩，針對我們的應用，我們是有一個公共框架的，所以我把這句話寫在了這個公用的頭文件中，
這樣所有包含它的程序都會被編譯成低版本的了。
另外一個常見的關於版本的函數問題，大概就是 memcpy了
同樣的，我們也寫下了這句話：
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
編譯之後高低版本都沒有問題了。免除了非得安裝個低版本系統的尷尬。
總結起來就是兩步
1. 用 objdump -T 查看程序哪個函數有版本問題；
2.用 __asm__(".symver ..."); 讓程序鏈接舊符號,並編譯之。