SUSE glibc升级为2.18过程记录

时间 2019-11-17

标签 suse glibc 升级 2.18 过程记录繁體版

原文原文链接

先验知识：
一、运行时，动态库的装载依赖于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中
二、编译时，搜索库的路径顺序以下：
（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”来查看）
三、二进制程序的搜索路径顺序为PATH环境变量中所设定。通常/usr/local/bin高于/usr/bin
四、编译时的头文件的搜索路径顺序，与library的查找顺序相似。通常/usr/local/include高于/usr/includehtml

先升级了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分钟。
java

若是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.）linux

成功后：

 
    [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变量：api

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

解决办法：
个人gmp, mpfr, mpc都是使用默认参数安装的，没指定任何参数服务器

./configure
make make install

因此直接使用下面的命令设置环境变量就能够了：测试

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

若是安装时指定了安装目录，使用相似下面的命令：ui

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.htmlspa

【工做】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库，这样命令就能够正常使用了。