SUSE glibc升級為2.18過程記錄

先驗知識：
1、運行時，動態庫的裝載依賴於ld-linux.so.6的實現，它查找共享庫的順序如下：
（1）ld-linux.so.6在可執行的目標文件中被指定，可用readelf命令查看
（2）ld-linux.so.6缺省在/usr/lib和lib中搜索；當glibc安裝到/usr/local下時，它查找/usr/local/lib
（3）LD_LIBRARY_PATH環境變量中所設定的路徑
（4）/etc/ld.so.conf（或/usr/local/etc/ld.so.conf）中所指定的路徑，由ldconfig生成二進制的ld.so.cache中
2、編譯時，搜索庫的路徑順序如下：
（1）ld-linux.so.6由gcc的spec文件中所設定
（2）gcc --print-search-dirs所打印出的路徑，主要是libgcc_s.so等庫。可以通過GCC_EXEC_PREFIX來設定
（3）LIBRARY_PATH環境變量中所設定的路徑，或編譯的命令行中指定的-L/usr/local/lib 
（2）binutils中的ld所設定的缺省搜索路徑順序，編譯binutils時指定。（可以通過“ld --verbose | grep SEARCH”來查看）
3、二進制程序的搜索路徑順序為PATH環境變量中所設定。一般/usr/local/bin高於/usr/bin
4、編譯時的頭文件的搜索路徑順序，與library的查找順序類似。一般/usr/local/include高於/usr/include

 

先升級了gcc為4.8.2，然后下載2.18的源碼安裝，源碼解壓后：
cd glibc-2.18
mkdir build
cd build
../configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin  
make && make install
需要等大概10分鍾。

如果configure時候自己指定安裝目錄會比較麻煩，見后面參考文章，自己就把庫搞錯了導致linux下所有命令都提示段錯誤。最后還是重新設置LD LIB變量解決的段錯誤恢復過來的。（Probably your LD_LIBRARY_PATH includes a dot / . and that Lib directory contains standard libraries like libc, so what ever command you issue, system picks a library from that path and something goes wrong.）

 

成功后：

[root @HY build]#  strings /lib64/libc.so. 6 | grep GLIBC

GLIBC_2. 2.5

GLIBC_2. 2.6

GLIBC_2. 3

GLIBC_2. 3.2

GLIBC_2. 3.3

GLIBC_2. 3.4

GLIBC_2. 4

GLIBC_2. 5

GLIBC_2. 6

GLIBC_2. 7

GLIBC_2. 8

GLIBC_2. 9

GLIBC_2. 10

GLIBC_2. 11

GLIBC_2. 12

GLIBC_2. 13

GLIBC_2. 14

GLIBC_2. 15

GLIBC_2. 16

...

GLIBC_2. 18

GLIBC_PRIVATE

 

 

 

安裝過程遇到的錯誤解決，因為gcc 4.8.2依賴庫的原因需要設置正確的LD LIB變量：

configure: error: cannot compute suffix of object files: cannot compile

解決辦法：
我的gmp, mpfr, mpc都是使用默認參數安裝的，沒指定任何參數

./configure
make make install

所以直接使用下面的命令設置環境變量就可以了：

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

如果安裝時指定了安裝目錄，使用類似下面的命令：

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gcc-4.6.3/mpc-0.9/mpc_install/lib:/opt/gcc-4.6.3/gmp-5.0.4/gmp_install/lib

參考：http://www.jiagoumi.com/work/811.html

【工作】Centos6.5 升級glibc解決“libc.so.6: version GLIBC_2.14 not found”報錯問題

寫在前面：

研發發來郵件說線上有台服務器跑程序報錯，信息如下：

./agent: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by./agent)

 

從上面報錯可以看出，程序運行時候，沒有找到“GLIBC_2.14”這個版本庫，而默認的Centos6.5 glibc版本最高為2.12, 所以需要更新系統glibc庫。

 

glibc是gnu發布的libc庫，即c運行庫，glibc是linux系統中最底層的api，幾乎其它任何運行庫都會依賴於glibc。glibc除了封裝linux操作系統所提供的系統服務外，它本身也提供了許多其它一些必要功能服務的實現。

 

很多linux的基本命令，比如cp, rm, ll,ln等，都得依賴於它，如果操作錯誤或者升級失敗會導致系統命令不能使用，嚴重的造成系統退出后無法重新進入，所以操作時候需要慎重。

解決辦法：

1.查看系統版本和glibc庫版本

# cat /etc/redhat-release 

CentOS release 6.5 (Final)

 

# strings /lib64/libc.so.6 |grep GLIBC_

GLIBC_2.2.5

GLIBC_2.2.6

GLIBC_2.3

GLIBC_2.3.2

GLIBC_2.3.3

GLIBC_2.3.4

GLIBC_2.4

GLIBC_2.5

GLIBC_2.6

GLIBC_2.7

GLIBC_2.8

GLIBC_2.9

GLIBC_2.10

GLIBC_2.11

GLIBC_2.12

GLIBC_PRIVATE

 

由上面的信息可以看出系統是CentOS 6.5，最高支持glibc的版本為2.12，而研發程序要2.14版本，所以需要升級。

 

2.下載軟件並升級：

# wget http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz 

# wget http://ftp.gnu.org/gnu/glibc/glibc-ports-2.14.tar.gz 

# tar -xvf  glibc-2.14.tar.gz 

# tar -xvf  glibc-ports-2.14.tar.gz

# mv glibc-ports-2.14 glibc-2.14/ports

# mkdir glibc-build-2.14

# cd glibc-build-2.14/ 

# ../glibc-2.14/configure  --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin

# make

 

注意：當make成功后，會在當前glibc-build-2.14目錄下生成一個新的libc.so.6的軟連接，指向的是本目錄下的libc.so文件，如下所示：

 

# ll glibc-build-2.14/libc.so.6

glibc-build-2.14/libc.so.6 -> libc.so

 

可以將上面的libc.so文件直接拷貝到/lib64下面改名為libc-2.14.so，刪除原來的libc.so.6軟連接，建立新的連接即可使用，但是此處有一個大坑，后面會介紹，此處還是按照正常流程安裝。

 

繼續完成后續的安裝： 

# make install 

 

以上完成不報錯的話，查看庫文件，發現/lib64/libc.so.6軟鏈接指向了2.14版本

 

# ll /lib64/libc.so.6 

/lib64/libc.so.6 -> /lib64/libc-2.14.so

 

3.再次查看glibc支持的版本：

# strings /lib64/libc.so.6 |grep GLIBC_

GLIBC_2.2.5

GLIBC_2.2.6

GLIBC_2.3

GLIBC_2.3.2

GLIBC_2.3.3

GLIBC_2.3.4

GLIBC_2.4

GLIBC_2.5

GLIBC_2.6

GLIBC_2.7

GLIBC_2.8

GLIBC_2.9

GLIBC_2.10

GLIBC_2.11

GLIBC_2.12

GLIBC_2.13

GLIBC_2.14

GLIBC_PRIVATE

 

可以看到glibc支持的版本已經到2.14，再次執行程序就不會報錯了。

其他知識點：

有些安裝方法是編譯時候指定的目錄不是/usr,而是通過建立軟鏈指向新的libc-2.14.so版本,在此過程中需要刪除原來連接，建立新的軟連接，但是此處有一個大坑，就是當你刪除libc.so.6之后會導致系統命令不可用,如下在測試機中演示的錯誤過程：

 

# rm -rf /lib64/libc.so.6

 

接下來當你建立新的軟鏈接時候，會發現ln命令不能用了。

# ln -s /lib64/libc-2.14.so /lib64/libc.so.6

ln: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

 

當出現上面的狀況時候，可以使用以下方法解決（假設libc-2.14.so已經拷貝到/lib64/目錄下）:

# LD_PRELOAD=/lib64/libc-2.14.so ln -s /lib64/libc-2.14.so /lib64/libc.so.6

 

當然如果升級失敗，還可以使用下面命令還原至系統升級前的版本libc-2.12.so: 

# LD_PRELOAD=/lib64/libc-2.12.so ln -s /lib64/libc-2.12.so /lib64/libc.so.6

 

“LD_PRELOAD”是一個環境變量，定義在程序運行前優先加載的動態鏈接庫，本處 作用就是在執行后面的ln命令時，指定使用的glibc庫，這樣命令就可以正常使用了。