[CENTOS] 安装glibc
2016-07-28 00:00
393 查看
在你准备升级GLIBC库之前,你要好好思考一下,
你真的要升级GLIBC么?
你知道你自己在做什么么?
http://baike.baidu.com/view/1323132.htm?fr=aladdin
glibc是gnu发布的libc库,即c运行库。glibc是linux系统中最底层的api,几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外,它本身也提供了许多其它一些必要功能服务的实现...
总的来说,不说运行在linux上的一些应用,或者你之前部署过的产品,就是很多linux的基本命令,比如cp, rm, ll之类,都得依赖于它
网上很多人有惨痛教训,甚至升级失败后系统退出后无法重新进入了。。
对于CentOS这样的系统,为了追求稳定性(这个值得商榷)往往各种库版本都很低,比如6.5甚至7.0自带的还是glibc2.12, 而ubuntu 14.04带glibc2.19
如果升级基本C运行库到一个太新的版本,可能会影响CentOS的运行。所以大家如果遇到CentOS基本库的问题,影响了自己程序的运行,应该可以考虑:
1. 在低版本的系统编译自己的产品,如果自己的产品确实不需要新版才支持的新特性
2. 用版本高的系统来编译,比如ubuntu,和centos的新版,但可能需要部署到较低版本,那么可以考虑用mock等技术制作更好的安装包,把依赖打入包内
3.利用容器技术,如Docker,在低版本的操作系统内,轻量级的隔离出一个虚拟运行环境,适应你的程序。
好在我遇到的问题是glibc2.15就满足要求升级后暂时没发现问题,所以大家可以参考我的方法:
首先查看先有的情况,在CentOS6.5下
$ ll /lib64/libc.so.6
lrwxrwxrwx 1 root root 19 Sep 23 08:29 /lib64/libc.so.6 -> /lib64/libc-2.12.so
libc.so.6是一个软连接,当前的glibc是2.12版本,我遇到的事GLIBC_2.15找不到的问题,所以需至少升级到2.15
首先,从网上下载glibc 2.15的rpm安装包,但这个不容易,因为.rpm针对的是centOS和redhat,高版本安装包很少见。也可以直接从其他系统上好一个编译好的文件
libc.so.6(对应glibc 2.15或者更高的),不过最保险的方式就是下载源代码在本地编译一次(有的人实在编译不成功,那也只能从别的地方找一份了)
各个版本的glibc可以从http://ftp.gnu.org/gnu/glibc/找,包括其插件glibc-port
最新到2.20,我保守的选择2.15
对于低版本glibc,还有glibc-linuxthreads-2.x需要编译,可参考很多网上文档,但2.15没有,所以不用了
wget http://ftp.gnu.org/gnu/glibc/glibc-2.15.tar.gz
wget http://ftp.gnu.org/gnu/glibc/glibc-ports-2.15.tar.gz
tar -xvf glibc-2.15.tar.gz
tar -xvf glibc-ports-2.15.tar.gz
mv glibc-ports-2.15 glibc-2.15/ports
mkdir glibc-build-2.15
cd glibc-build-2.15
../glibc-2.15/configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
make
make install
如果提示install成功,去看glibc所在的共享库:
ll /lib64/libc*
可以看到2.12的旧库文件还在,多了2.15版本的库文件,而且软链接文件全部指向了2.15版本。
-rwxr-xr-x 1 root root 1921096 Aug 30 02:16 /lib64/libc-2.12.so
-rwxr-xr-x 1 root root 9801632 Sep 25 13:46 /lib64/libc-2.15.so
lrwxrwxrwx. 1 root root 18 May 19 18:51 /lib64/libcap-ng.so.0 -> libcap-ng.so.0.0.0
-rwxr-xr-x. 1 root root 18672 Jun 25 2011 /lib64/libcap-ng.so.0.0.0
lrwxrwxrwx. 1 root root 14 May 19 18:51 /lib64/libcap.so.2 -> libcap.so.2.16
-rwxr-xr-x 1 root root 19016 Dec 8 2011 /lib64/libcap.so.2.16
lrwxrwxrwx. 1 root root 19 May 19 18:57 /lib64/libcgroup.so.1 -> libcgroup.so.1.0.40
-rwxr-xr-x 1 root root 97016 Dec 9 2013 /lib64/libcgroup.so.1.0.40
-rwxr-xr-x 1 root root 197064 Aug 30 02:16 /lib64/libcidn-2.12.so
-rwxr-xr-x 1 root root 267972 Sep 25 13:46 /lib64/libcidn-2.15.so
lrwxrwxrwx 1 root root 15 Sep 25 13:52 /lib64/libcidn.so.1 -> libcidn-2.15.so
lrwxrwxrwx. 1 root root 17 May 19 18:51 /lib64/libcom_err.so.2 -> libcom_err.so.2.1
-rwxr-xr-x 1 root root 17256 Nov 22 2013 /lib64/libcom_err.so.2.1
-rwxr-xr-x 1 root root 40400 Aug 30 02:16 /lib64/libcrypt-2.12.so
-rwxr-xr-x 1 root root 142947 Sep 25 13:46 /lib64/libcrypt-2.15.so
lrwxrwxrwx. 1 root root 22 May 19 18:57 /lib64/libcryptsetup.so.1 -> libcryptsetup.so.1.1.0
-rwxr-xr-x 1 root root 97072 Jun 22 2012 /lib64/libcryptsetup.so.1.1.0
lrwxrwxrwx 1 root root 16 Sep 25 13:52 /lib64/libcrypt.so.1 -> libcrypt-2.15.so
lrwxrwxrwx 1 root root 12 Sep 25 13:52 /lib64/libc.so.6 -> libc-2.15.so
有些人会在make install后出现error。这儿error我没去细究,经过网友提醒,可能是因为没有sudo造成的,因为make install就是把文件拷贝到几个受保护的系统目录下。
如果还是不行,可以查看一下系统此时的GLIBC版本,参考一开始的做法。如果版本未升级,我们只能手动安装一下:
首先make是成功了,那么我们会发现build目录下编译出了一个新的libc.so.6 (/glibc-build-2.15/libc.so.6, 我们会发现这实际上也是一个软连接,真实的lib文件时libc.so, 输出
$ ll libc.so.6
lrwxrwxrwx 1 root root 7 Sep 23 07:41 libc.so.6 -> libc.so
[usr@linux glibc-build-2.15]$ strings libc.so | 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_PRIVATE
这是我们需要的lib了,然后去更新系统的库。
这里要注意,更新系统里的链接(我的是/lib64/libc.so.6) 很容易出错,我不清楚有没有更好的办法,一般都是删除旧链接,建立新链接
但删除旧链接后,很多命令直接不能用了,因为此时中不到glibc的库了。这个时候就需要临时指定一个glibc库,方法如下(libc.so改个名以便好以后更新的其他版本区分):
[usr@linux cp /****/glibc-build-2.15/libc.so /lib64/libc-2.15.so
rm -rf /lib64/libc.so.6
LD_PRELOAD=/lib64/libc-2.15.so ln -s/lib64/libc-2.15.so lib64/libc.so.6
更新连接完毕,然后:
$ 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_PRIVATE
说明连接更新成功,再编译的话,GLIBC_2.15及以下版本的依赖问题就不会出现了。
你真的要升级GLIBC么?
你知道你自己在做什么么?
http://baike.baidu.com/view/1323132.htm?fr=aladdin
glibc是gnu发布的libc库,即c运行库。glibc是linux系统中最底层的api,几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外,它本身也提供了许多其它一些必要功能服务的实现...
总的来说,不说运行在linux上的一些应用,或者你之前部署过的产品,就是很多linux的基本命令,比如cp, rm, ll之类,都得依赖于它
网上很多人有惨痛教训,甚至升级失败后系统退出后无法重新进入了。。
对于CentOS这样的系统,为了追求稳定性(这个值得商榷)往往各种库版本都很低,比如6.5甚至7.0自带的还是glibc2.12, 而ubuntu 14.04带glibc2.19
如果升级基本C运行库到一个太新的版本,可能会影响CentOS的运行。所以大家如果遇到CentOS基本库的问题,影响了自己程序的运行,应该可以考虑:
1. 在低版本的系统编译自己的产品,如果自己的产品确实不需要新版才支持的新特性
2. 用版本高的系统来编译,比如ubuntu,和centos的新版,但可能需要部署到较低版本,那么可以考虑用mock等技术制作更好的安装包,把依赖打入包内
3.利用容器技术,如Docker,在低版本的操作系统内,轻量级的隔离出一个虚拟运行环境,适应你的程序。
好在我遇到的问题是glibc2.15就满足要求升级后暂时没发现问题,所以大家可以参考我的方法:
首先查看先有的情况,在CentOS6.5下
$ ll /lib64/libc.so.6
lrwxrwxrwx 1 root root 19 Sep 23 08:29 /lib64/libc.so.6 -> /lib64/libc-2.12.so
libc.so.6是一个软连接,当前的glibc是2.12版本,我遇到的事GLIBC_2.15找不到的问题,所以需至少升级到2.15
首先,从网上下载glibc 2.15的rpm安装包,但这个不容易,因为.rpm针对的是centOS和redhat,高版本安装包很少见。也可以直接从其他系统上好一个编译好的文件
libc.so.6(对应glibc 2.15或者更高的),不过最保险的方式就是下载源代码在本地编译一次(有的人实在编译不成功,那也只能从别的地方找一份了)
各个版本的glibc可以从http://ftp.gnu.org/gnu/glibc/找,包括其插件glibc-port
最新到2.20,我保守的选择2.15
对于低版本glibc,还有glibc-linuxthreads-2.x需要编译,可参考很多网上文档,但2.15没有,所以不用了
wget http://ftp.gnu.org/gnu/glibc/glibc-2.15.tar.gz
wget http://ftp.gnu.org/gnu/glibc/glibc-ports-2.15.tar.gz
tar -xvf glibc-2.15.tar.gz
tar -xvf glibc-ports-2.15.tar.gz
mv glibc-ports-2.15 glibc-2.15/ports
mkdir glibc-build-2.15
cd glibc-build-2.15
../glibc-2.15/configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
make
make install
如果提示install成功,去看glibc所在的共享库:
ll /lib64/libc*
可以看到2.12的旧库文件还在,多了2.15版本的库文件,而且软链接文件全部指向了2.15版本。
-rwxr-xr-x 1 root root 1921096 Aug 30 02:16 /lib64/libc-2.12.so
-rwxr-xr-x 1 root root 9801632 Sep 25 13:46 /lib64/libc-2.15.so
lrwxrwxrwx. 1 root root 18 May 19 18:51 /lib64/libcap-ng.so.0 -> libcap-ng.so.0.0.0
-rwxr-xr-x. 1 root root 18672 Jun 25 2011 /lib64/libcap-ng.so.0.0.0
lrwxrwxrwx. 1 root root 14 May 19 18:51 /lib64/libcap.so.2 -> libcap.so.2.16
-rwxr-xr-x 1 root root 19016 Dec 8 2011 /lib64/libcap.so.2.16
lrwxrwxrwx. 1 root root 19 May 19 18:57 /lib64/libcgroup.so.1 -> libcgroup.so.1.0.40
-rwxr-xr-x 1 root root 97016 Dec 9 2013 /lib64/libcgroup.so.1.0.40
-rwxr-xr-x 1 root root 197064 Aug 30 02:16 /lib64/libcidn-2.12.so
-rwxr-xr-x 1 root root 267972 Sep 25 13:46 /lib64/libcidn-2.15.so
lrwxrwxrwx 1 root root 15 Sep 25 13:52 /lib64/libcidn.so.1 -> libcidn-2.15.so
lrwxrwxrwx. 1 root root 17 May 19 18:51 /lib64/libcom_err.so.2 -> libcom_err.so.2.1
-rwxr-xr-x 1 root root 17256 Nov 22 2013 /lib64/libcom_err.so.2.1
-rwxr-xr-x 1 root root 40400 Aug 30 02:16 /lib64/libcrypt-2.12.so
-rwxr-xr-x 1 root root 142947 Sep 25 13:46 /lib64/libcrypt-2.15.so
lrwxrwxrwx. 1 root root 22 May 19 18:57 /lib64/libcryptsetup.so.1 -> libcryptsetup.so.1.1.0
-rwxr-xr-x 1 root root 97072 Jun 22 2012 /lib64/libcryptsetup.so.1.1.0
lrwxrwxrwx 1 root root 16 Sep 25 13:52 /lib64/libcrypt.so.1 -> libcrypt-2.15.so
lrwxrwxrwx 1 root root 12 Sep 25 13:52 /lib64/libc.so.6 -> libc-2.15.so
有些人会在make install后出现error。这儿error我没去细究,经过网友提醒,可能是因为没有sudo造成的,因为make install就是把文件拷贝到几个受保护的系统目录下。
如果还是不行,可以查看一下系统此时的GLIBC版本,参考一开始的做法。如果版本未升级,我们只能手动安装一下:
首先make是成功了,那么我们会发现build目录下编译出了一个新的libc.so.6 (/glibc-build-2.15/libc.so.6, 我们会发现这实际上也是一个软连接,真实的lib文件时libc.so, 输出
$ ll libc.so.6
lrwxrwxrwx 1 root root 7 Sep 23 07:41 libc.so.6 -> libc.so
[usr@linux glibc-build-2.15]$ strings libc.so | 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_PRIVATE
这是我们需要的lib了,然后去更新系统的库。
这里要注意,更新系统里的链接(我的是/lib64/libc.so.6) 很容易出错,我不清楚有没有更好的办法,一般都是删除旧链接,建立新链接
但删除旧链接后,很多命令直接不能用了,因为此时中不到glibc的库了。这个时候就需要临时指定一个glibc库,方法如下(libc.so改个名以便好以后更新的其他版本区分):
[usr@linux cp /****/glibc-build-2.15/libc.so /lib64/libc-2.15.so
rm -rf /lib64/libc.so.6
LD_PRELOAD=/lib64/libc-2.15.so ln -s/lib64/libc-2.15.so lib64/libc.so.6
更新连接完毕,然后:
$ 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_PRIVATE
说明连接更新成功,再编译的话,GLIBC_2.15及以下版本的依赖问题就不会出现了。
glibc-2.11编译报错 ../sysdeps/i386/fpu/s_frexp.S: Assembler messages: ../sysdeps/i386/fpu/s_frexp.S:66: Error: invalid identifier for ".ifdef" ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: unrecognized symbol type "" ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: expected comma after name `' in .size directive ../sysdeps/i386/fpu/s_frexp.S:66: Error: ".endif" without ".if" ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk `.get_pc_thunk.dx' after expression
解决方法见:http://www.eglibc.org/archives/patches/msg00073.html Index: sysdeps/unix/sysv/linux/i386/sysdep.h =================================================================== --- sysdeps/unix/sysv/linux/i386/sysdep.h (revision 1469) +++ sysdeps/unix/sysv/linux/i386/sysdep.h (working copy) @@ -29,6 +29,10 @@ #include <dl-sysdep.h> #include <tls.h> +#if defined __i686 && defined __ASSEMBLER__ +#undef __i686 +#define __i686 __i686 +#endif /* For Linux we can use the system call table in the header file /usr/include/asm/unistd.h Index: nptl/sysdeps/pthread/pt-initfini.c =================================================================== --- nptl/sysdeps/pthread/pt-initfini.c (revision 1469) +++ nptl/sysdeps/pthread/pt-initfini.c (working copy) @@ -45,6 +45,11 @@ /* Embed an #include to pull in the alignment and .end directives. */ asm ("\n#include \"defs.h\""); +asm ("\n#if defined __i686 && defined __ASSEMBLER__"); +asm ("\n#undef __i686"); +asm ("\n#define __i686 __i686"); +asm ("\n#endif"); + /* The initial common code ends here. */ asm ("\n/*@HEADER_ENDS*/");
相关文章推荐
- 用python获取linux下一个目录下一级目录的各自大小
- linux icmp 禁用问题
- exec函数的使用
- 虚拟机的centOS里可以访问PHP脚本,而windows下不能访问
- Linux运维学习-1——2016年7月19日
- Linux回传码
- linux下的find文件查找命令与grep文件内容查找命令
- Linux下,延长SSH的连接超时时间
- linux nand flash 驱动简单介绍
- 安装vmtools for linux
- <实训|第七天>横扫Linux磁盘分区、软件安装障碍附制作软件仓库
- 将RHEL7/centos7系统网卡名称eno16777736改为eth0
- linux文件系统结构及简单操作
- Linux之使用帮助
- 新环境部署(linux硬盘挂载项目迁移启动)
- 中标麒麟操作系统设置或修改root密码
- Linux初体验(二)
- Linux环境下5种I/O模型
- Linux中的history命令
- 内核模块遍历进程