這是我在做計算實驗程序時碰到的一個小問題。場景是這樣的，自己的機器上運行的是ubuntu8.10,gcc 4.2，也經常apt-get update。用于運行計算任務的是學院的一臺IBM cluster 1350服務器，上面的系統是 rhel3。在ubuntu下編輯編譯好程序，將執行文件放入服務器上運行。出問題之前，在程序中沒有#include <stdlib.h>，ubuntu下的程序在rhel3上運行良好。加了#include <stdlib.h>后，在rhel3中運行出現問題 /lib/tls/libc.so.6: version `GLIBC_2.4' not found 。問題是小問題，但也學了不少知識，看下面分析過程。
分析一，stdlib.h包文件包含在那個包中？glibc是GNU c函數庫，這提供給我們編寫c代碼的大部分庫函數，這個stdlib.h也在其中咯。但是rhel3上也是有glibc的，yum -qa|grep glibc，是glibc-2.3.2-95.30，低于2.4，但為什么出現了版本依賴問題呢？已知信息：編輯和編譯的平臺是ubuntu，運行的平臺是redhat，系統兼容問題；ubuntu的包都被我時常更新，redhat 則是e as3，里面的包比較舊。按照這樣的思路，在redhat上安裝了glibc_2.4的包后，程序如期能夠運行。還有東西可學，繼續...
分析二，既然開始認為不同linux之間，可能出現問題，那么就找了另外一臺redhat系統，redhat as4, glibc.2.3.4，高于服務器的glibc-2.3.2。將程序在redhat as4上編譯成執行文件，拷貝到redhat as3上運行，也可以正常運行。哎？這個為什么就行了！可見不同linux系統之間的編程環境差別性有待進一步學習。
分析三，既然是包依賴的問題，那么看看是否可以避免這個包依賴。在編譯時采用的是動態連接的方式，如果采用靜態連接的編譯，會不會就好了。加入/usr/lib/libc.a，得到了比原來大許多的執行文件，拷入redhat as3上，依然出現同樣問題；加入-static /usr/lib/libc.a，得到的執行文件還要更大一些，放入redhat as3上執行，反饋是 “FATAL: kernel too old Segmentation fault ” 。靜態連接的含義是什么？靜態連接編譯出的執行文件在執行的時候，調用包含在頭文件里的庫函數的順序規則是什么？Linux中靜態鏈接與動態鏈接涉及到Linux共享函數庫。共享函數庫是為了供開發方便和減少冗余，里面包含了常用的函數。動態鏈接得到的執行文件在執行的時候，會動態調用庫中的函數，它的執行文件中沒有包含庫函數的實體，因而執行文件相應就會小些；而靜態鏈接則是將要調用的庫中函數鏈接到執行文件當中，這樣執行文件中就有一份庫函數拷貝了，在執行的時候就不用去調用共享庫中的函數而是直接使用這份拷貝，但文件相應會大了許多。依照此分析，我用-static(這個參數禁止使用了共享庫，所以不用關心共享庫而直接執行)編譯出的文件，在redhat as3上執行的反饋是kernel too old，說明了在執行我的執行文件時，kernel版本和glibc版本之間還出現了沖突。（PS：在google "fatal:kernel too old"得到的大多數文檔中，是問在編譯內核時出現了這個錯誤，回答是和glibc相關）那么內核和glibc的關系有是什么呢？[6]
關于glibc的文件解釋
[1]
http://blog.csdn.net/My_emdebed/archive/2007/04/22/1574746.aspx靜態鏈接libc的一個例子
[2]
http://www.9php.com/FAQ/cxsjl/c/2007/04/704307080637.html進一步了解靜態鏈接和動態鏈接
[3]
http://cmdblock.blog.51cto.com/415170/86802gcc筆記
[4]
http://www.cublog.cn/u/13991/showart.php?id=96714 [5]
http://www.bloghome.cn/posts/10410 GCC,glibc,kernel的要點//Linux發布程序要注意版本的軟件包
[6]http://www.linux-cn.com/html/linux/network/20080818/57908.html