使用源代码将 Glibc 升级到 2.6　

最新推荐文章于 2024-11-01 12:20:35 发布

weixin_33712987

最新推荐文章于 2024-11-01 12:20:35 发布

阅读量123

点赞数

文章标签：数据库操作系统开发工具

原文链接：http://blog.51cto.com/huangbao/152678

版权

本文介绍了一种使用源代码的方式升级系统标准动态库到 Glibc2.6 的方法。该方法是安全的，即使遇到升级失败，也能把系统恢复为原来的状态。系统环境不同，源代码的编译和安装方法会有很大的差异，因此本文也只能针对一种特定的平台（Mandriva Linux release 2006.0）的 Glibc 进行升级。撰写本文的目的，是为了给出一个升级 Glibc 的例子，读者可以参考本文介绍的方法升级 Glibc，但是一定要根据系统的实际情况作相应的调整。

简介

有些软件可能要求系统的 Glibc 高于某个版本才可以正常运行。如果您的 Glibc 低于要求的版本，为了运行这些软件，您就不得不升级您的 Glibc 了。您可以寻找已经编译好的 rpm 包或者使用源代码的方式升级 Glibc。

使用源代码方式升级 Glibc 是需要小心考虑的事情，因为整个系统几乎所有应用程序都依赖于原有的动态库，升级的时候，执行"make install"命令会打断旧的动态库链接，改为指向新的库文件。在这个过程中，不同的链接指向新旧不同版本的库文件，很容易导致系统崩溃，崩溃后，一般是无法重新启动的。

笔者使用的Linux发行版本是Mandriva Linux release 2006.0，其Glibc版本是2.3.5，内核版本是2.6.12-12mdk。由于某些需要，笔者必须升级原来的Glibc到更高的版本。经过实践，成功使用源代码的方式安全地把Glibc从2.3.5升级到2.6。使用相同的方法，也能成功升级到Glibc2.4或Glibc2.5。成功升级后，还可以在新旧不同版本的Glibc之间自由切换。

如果您需要阅读有关升级Glibc的文档，可以阅读 Glibc 2 HOWTO文档，该文论述了如何从libc5升级到libc6，但是现在的Linux发行版的Glibc都已经使用libc6，更多的需要是在libc6 的范围内，从低版本升级到更高的版本。另外您可以阅读Linux From Scratch项目有关如何安装Glibc的文档。笔者认为最有必要阅读的是Glibc源程序目录树下的INSTALL和FAQ文档，INSTALL详细描述了有关各编译选项的具体作用，FAQ回答了很多具体的问题。

回页首

升级Glibc的流程

为了安全升级Glibc，在升级前必须做好详细的部署和备份，即使是升级失败，系统也要能够还原为原来的状态。升级Glibc失败后，一般是无法重新启动系统的，必须使用另外一个可以启动计算机的Linux系统启动，挂载升级失败的根文件系统，恢复系统的Glibc为原来的状态。因此，准备另外一个可以启动的Linux系统，是必需的。

准备好另外一个可以启动的Linux系统后，接下来的工作是编译Glibc。编译前要执行"configure"命令，用户可以根据自己的需要，加入不同的编译选项，编译选项在INSTLL文件里有详细的说明。如果是升级当前的 Glibc，必须使用--prefix＝/usr选项，该选项指定当前即将编译的Glibc作为系统的标准动态库，安装的时候，Glibc会修改 /lib，/usr等目录下的文件和链接。如果--prefix不是指向/usr，譬如--prefix=/glibc, 安装的时候，Glibc只会在/glibc目录下生成目录，文件以及链接，安装后的Glibc不会成为系统的标准动态库。如果不指定--prefix， Glibc缺省认为--prefix=/usr/local，安装后的Glibc也不会成为系统的标准动态库。编译Glibc的时候需要使用Linux内核的头文件，如果内核的头文件太旧，执行"make"的时候，可能会失败，这时可以在configure的时候，使用--with-headers选项指定新内核的头文件的所在目录。笔者的Mandriva Linux release 2006.0的内核头文件就不能令Glibc2.6成功编译，但是却能令Glibc2.4和Glibc2.5成功编译，使用--with-headers 指向新内核的头文件后，Glibc2.6也能成功编译，下文将会有详细叙述。

Glibc安装的时候，会直接修改/lib，/usr/lib等目录下的文件和链接，为了在升级失败的情况下能够恢复系统的Glibc为原来状态，在安装新版本的Glibc之前必须对一些重要目录进行备份，至于哪些目录需要做备份，下文将会有叙述。

备份好重要目录后就可以安装Glibc了，必须由root用户执行make install命令，不同的Linux发行版，可能会有不同的结果。笔者使用的Mandriva Linux release 2006.0在这个过程中会出现错误，并且输入任何命令都无效，重新启动也无法再次进入Linux系统。出现的这样的错误是由于Coreutils的命令都是依赖于/usr/tls/目录下的链接文件，这些链接文件都指向原来的Glibc动态库文件，而/lib/ld-linux.so.2已经被改为指向新版本的Glibc动态库文件了，这些重要链接分别指向新旧不同版本的库文件，导致了执行Coreutils的命令无效。这个时候，就要用另外一个 Linux系统启动，把/usr/tls/目录下的链接修改为指向新版本的Glibc的库文件。

经过上述修改，重新启动计算机，如果能重新进入原Linux系统，表明到目前为止升级过程都是正确的。这个时候，要再执行一次"make install"重新安装Glibc，正常情况下，这次不会出现任何错误，安装结束的时候，Glibc会给出安装成功的消息。如果修改/lib/tls/ 下的链接后重新启动计算机仍然不能进入原Linux系统，表明这次升级失败，只能再次使用另外一个Linux系统启动，挂载升级失败的根文件系统，把先前备份好的重要目录恢复为原来的名字，经过这样的恢复，一般是可以重新启动升级失败的Linux系统的。

升级的最后一步是执行"make localedata/install-locales"命令安装时区和地区数据库。

图一：升级Glibc的流程图

回页首

注意

本文介绍的方法在升级过程中会出现一次链接错误，系统无法输入命令，重新启动也无法进入Linux，必须使用另外一个Linux系统启动，并挂载原根文件系统，修正在升级过程中产生的错误链接，然后才能继续升级。因此在升级之前，一定要先确保拥有另外一个可启动的Linux系统。此外，还要备份下文将会论述的一些重要目录，如果最终升级失败，需要用另外一个Linux系统启动，恢复原Linux系统的Glibc为原来的版本。

建议在升级之前，详细阅读Glibc源代码包内的INSTALL和FAQ文件。

回页首

升级过程

本文假设进行编译的用户名字是xyz，用户目录是/home/xyz/，所有源代码都在/home/xyz/build/目录下编译。所有源代码压缩包都已经拷贝到/home/xyz/build/目录下。升级Glibc的Linux系统的根文件系统使用hda5分区，其文件系统格式为xfs。

1 准备另外一个可启动的Linux系统

准备另外一个可启动的Linux系统的方法有很多，可以在硬盘上安装另外一个Linux发行版，可以在DOS环境下使用loadlin.exe启动一个 Linux系统，最简单的方式是使用Live CD，从光驱启动。无论使用什么形式，它都必须能挂载需要升级Glibc的根文件系统。

如果选择Live CD启动，Knoppix是一个很好的选择。您可以从Knoppix的网站下载iso文件，烧制成启动CD，也可以把Knoppix的系统文件拷贝到硬盘上，在DOS环境下，执行loadlin.exe启动。笔者使用了Knoppix 5.0.1，制作成Live CD启动。参考资料有介绍如何使用 Knoppix 进行系统恢复。

2 编译

Glibc的编译安装与一般的软件很类似，都是要经过configure，make和make install三个阶段。Glibc不能在源代码目录下编译，必须在一个空目录下编译。

编译Glibc是需要内核头文件的，笔者的Mandriva Linux release 2006.0的内核版本是2.6.12-12mdk，可以直接使用该版本内核的头文件升级到Glibc2.4 和Glibc2.5。如果升级到Glibc2.6，在make过程中，会出现以下错误：

libc_pic.os: In function `sync_file_range':
: undefined reference to `.Lpseudo_end'
collect2: ld returned 1 exit status

这是由于2.6.12-12mdk的内核头文件太旧，为了顺利编译Glibc2.6，必须使用新的内核头文件。

2.1 编译Glibc2.4或Glibc2.5

如果要升级Glibc到2.4或2.5，configure的时候只需要--prefix=/usr一个选项，意思是该Glibc将会作为系统的标准动态库。

以升级到Glibc2.5为例，执行以下命令进行编译：

$ cd ~/build
$ tar xjf glibc-2.5.tar.bz2
$ mkdir glibc-2.5-build
$ cd glibc-2.5-build
$ ../glibc-2.5/configure --prefix=/usr
$ make

glibc-2.5.tar.bz2是 Glibc2.5的源代码压缩包，执行"tar xjf glibc-2.5.tar.bz2"命令后，在~/build/目录下产生了glibc-2.5目录树，Glibc2.5的源代码就在这个目录里面。 Glibc不能在源代码目录下编译，因此执行了"mkdir glibc-2.5-build"命令，生成glibc-2.5-build目录，编译Glibc2.5时产生的文件，保存在这个目录下。如果顺利，将会成功编译，不会出现错误信息。

2.2 编译Glibc2.6

如果您打算升级到Glibc2.6，使用版本为2.6.12-12mdk的内核头文件是不能成功编译的，必须使用新的内核头文件。configure的时候使用--with-headers选项指向新的内核头文件的目录。Glibc的FAQ文档明确指出最好使用最新版本的内核头文件，而且编译时需要的内核头文件的版本不需要与当前正在运行的内核版本一致。笔者试验了版本为linux-2.6.20.7和linux-2.6.18两个版本的内核头文件，编译时系统运行的内核版本是2.6.12-12mdk，都可以成功编译Glibc2.6。

为了使用新版本的内核头文件，解开新版本的内核压缩包后，在源代码目录下执行"make menuconfig"，这将会进入内核的设置页面，不需要作任何处理，直接退出并保存。然后执行"make"，不需要等待make完毕，一开始看到

SYMLINK include/asm -> include/asm-i386

就可以按下ctrl+c停止编译内核。执行"make"的目的是在内核源代码目录树内生成一些重要的文件和软链接，其中在include/目录下产生一个名为asm的软链接指向asm-i386目录，没有这个链接，Glibc2.6是无法编译的。

假设使用linux-2.6.20.7的内核头文件，执行以下命令：

$ cd ~/build
$ tar xjf linux-2.6.20.7.tar.bz2
$ cd linux-2.6.20.7
$ make menuconfig
$ make

linux-2.6.20.7.tar.bz2 是2.6.20.7版本的Linux内核源代码压缩包，执行"tar xjf linux-2.6.20.7.tar.bz2"命令后，将会产生linux-2.6.20.7目录，Linux内核的源代码都在这个目录下，其中内核头文件在linux-2.6.20.7/include/下。确保linux-2.6.20.7/include/asm已经产生后，就可以停止内核的编译，然后进行Glibc2.6的编译：

$ cd ~/build
$ tar xjf glibc-2.6.tar.bz2
$ mkdir glibc-2.6-build
$ cd glibc-2.6-build
$ ../glibc-2.6/configure --prefix=/usr --with-headers=~/build/linux-2.6.20.7/include
$ make

glibc-2.6.tar.bz2是Glibc2.6的源代码压缩包，执行"tar xjf glibc-2.6.tar.bz2"命令后，在~/build/目录下产生了glibc-2.6目录树。

如果您的系统当前运行的内核已经升级到比较新的版本，例如2.6.20.7，configure的时候，就不需要--with-headers选项了，与 Glibc2.4或Glibc2.5的configure命令一样，只需要--prefix=/usr选项就可以了，但是前提条件是 /lib/modules/`uname -r`/source指向内核的源程序目录，您可以用以下命令查看它指向哪里：

$ ls -l /lib/modules/`uname -r`/

3．make install前的准备工作

3.1 哪些目录需要备份？

安装Glibc前必须备份好原来的系统动态库，一旦安装失败，使用另外一个Linux系统启动，挂载升级失败的根文件系统，还原Glibc为原来的状态。可是哪些目录需要备份？Glibc在安装的时候，将会修改哪个目录下的文件？

Glibc 在安装时可以指定install_root选项，命令Glibc把该选项指向的目录作为根，文件都安装到这个目录下，通过观察Glibc在这个目录里生成了什么目录和文件，我们就可以知道Glibc在安装的时候到底会修改哪些目录了。假设安装到~/build/system_fake_root上：

$ cd ~/build
$ cd glibc-2.6-build
$ make install install_root=~/build/system_fake_root

安装后：

$ ls ~/build/system_fake_root
etc/  lib/  sbin/  usr/

可以看出，Glibc的make install命令会修改/etc，/lib，/sbin和/usr目录下的文件。这里最重要的是/lib和/usr。一般来说/usr目录下有很多文件，占用硬盘空间很大，实际也不需要对整个/usr目录备份，使用以下命令查看Glibc会修改/usr/下的哪些目录：

$ ls ~/build/system_fake_root/usr
bin/  include/  info/  lib/  libexec/  sbin/  share/

经分析，笔者选择了备份/lib，/usr/lib，/usr/include，/usr/sbin和/usr/bin。您当然可以备份更多的目录，不过笔者发现备份上述5个目录已经可以恢复系统的Glibc为原来的版本了。

3.2 备份目录

使用su命令切换为root。执行:

# cp -a /lib /lib.2.3.5
# cd /usr
# cp -a lib lib.2.3.5
# cp -a bin bin.2.3.5
# cp -a sbin sbin.2.3.5
# cp -a include include.2.3.5

经过以上步骤，就备份了以后还原用的目录。备份的目录名字使用原目录名后加上.2.3.5后缀，目的是区分不同的Glibc版本目录。

3.3 如何还原系统的Glibc

如果升级最终失败，导致系统无法启动，就必须使用另外一个Linux系统启动，还原上述备份的目录为原来的名字。以笔者的系统为例，升级失败的根文件系统使用hda5分区，其文件系统格式为xfs，将被挂载到/mnt/m1目录。使用Knoppix 5.0.1 Live CD启动后，打开一个控制台，执行"su"命令切换为root用户，执行以下命令

# cd /mnt
# mkdir m1
# mount -t xfs /dev/hda5 /mnt/m1
# cd /mnt/m1
# rm -fr lib
# mv lib.2.3.5 lib
# cd usr
# rm -fr lib bin sbin include
# mv lib.2.3.5 lib
# mv bin.2.3.5 bin
# mv sbin.2.3.5 sbin
# mv include.2.3.5 include

执行上述命令后，Glibc已经被恢复为原来的版本，系统应该可以正常启动。

3.4 如何知道当前的Glibc版本

Mandriva Linux release 2006.0的动态库是Glibc2.3.5。执行"/lib/libc.so.6"可以知道当前的Glibc是什么版本：

$ /lib/libc.so.6
GNU C Library stable release version 2.3.5, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0).
Compiled on a Linux 2.6.12 system on 2005-08-30.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton 
        libthread_db work sponsored by Alpha Processor Inc
Thread-local storage support included.
For bug reporting instructions, please see:
<[url]http://www.gnu.org/software/libc/bugs.html>.[/url]

从以上输出可以看到，当前系统的Glibc版本是2.3.5，使用Gcc4.0.1编译，编译时运行的Linux内核版本是2.6.12。

Glibc的FAQ文档给出以下程序用于查看当前的Glibc的版本：

#include <stdio.h>
#include <gnu/libc-version.h>
int main (void) { puts (gnu_get_libc_version ()); return 0; }

把上述程序写到chk_lib_v.c文件，执行以下命令编译：

gcc -o chk_lib_v chk_lib_v.c

执行chk_lib_v后有以下输出：

$ ./chk_lib_v
2.3.5

3.5 注意Coreutils依赖的动态库情况

Mandriva Linux release 2006.0系统的/lib/目录下有个tls目录。该目录下的文件是能否成功升级Glibc到2.6的关键。使用ldd命令查看Coreutils的应用程序依赖的动态库情况可以发现：

        $ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/tls/librt.so.1 (0xb7f60000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7f5b000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f54000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e26000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7e14000)
        /lib/ld-linux.so.2 (0xb7f89000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7e10000)

请注意上述的librt.so.1，libc.so.6和libpthread.so.0，它们都是位于/lib/tls/，而不是/lib/。换言之， ls的执行，依赖于/lib/tls目录下的某些动态链接库文件。tls是thread-local storage，当不同的线程使用同一个全局变量的时候，各线程将会在本地保留该变量的备份，查阅参考资料可以了解更多有关tls的信息。 Glibc2.4，Glibc2.5和Glibc2.6都支持tls。

/lib/tls/下有以下文件：

$ ls -l /lib/tls
总用量 1488
-rw-r--r--  1 root root 1229976  8月 30  2005 libc-2.3.5.so
lrwxrwxrwx  1 root root      13  5月 12 21:25 libc.so.6 -> libc-2.3.5.so
-rw-r--r--  1 root root  145176  8月 30  2005 libm-2.3.5.so
lrwxrwxrwx  1 root root      13  5月 12 21:25 libm.so.6 -> libm-2.3.5.so
-rw-r--r--  1 root root   84987  8月 30  2005 libpthread-0.10.so
lrwxrwxrwx  1 root root      18  5月 12 21:25 libpthread.so.0 -> libpthread-0.10.so
-rw-r--r--  1 root root   30620  8月 30  2005 librt-2.3.5.so
lrwxrwxrwx  1 root root      14  5月 12 21:25 librt.so.1 -> librt-2.3.5.so
-rw-r--r--  1 root root   22108  8月 30  2005 libthread_db-1.0.so
lrwxrwxrwx  1 root root      19  5月 12 21:25 libthread_db.so.1 -> libthread_db-1.0.so

/lib/tls目录下的文件是一些很重要的动态库及软连接，其中包括libc.so.6，它们都是指向2.3.5版本的动态库文件。

4. 安装Glibc2.6

4.1 第一次make install

切换到root用户，执行make install就开始安装Glibc了：

$ cd ~/build
$ cd glibc-2.6-build
$ su
# make install

在安装过程中，将会出现如下错误：

/home/xyz/build/glibc-2.6-build/elf/sln
/home/xyz/build/glibc-2.6-build/elf/symlink.list
rm -f /home/xyz/build/glibc-2.6-build/elf/symlink.list
rm: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, \
      version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
make[1]: *** [install-symbolic-link] Error 127
make[1]: Leaving directory `/home/xyz/build/glibc-2.6'
make: *** [install] Error 2

安装失败后，输入任何命令都是无效的，系统只会重复"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息，重新启动计算机在启动中就会失败，根本无法进入原Linux系统。

出现这样的错误的原因是Coreutils的应用程序都依赖于/lib/tls/下的动态库，在make install的时候，/lib/ld-linux.so.2从原来指向ld-2.3.5.so被改为指向ld-2.6.so，但这个时候 /lib/tls/libc.so.6指向的仍然是/lib/tls/libc-2.3.5.so。/lib/ld-linux.so.2和 /lib/tls/libc.so.6各自指向不同版本的库文件导致了Coreutils的命令执行失败，从而make install也失败。

这个时候，就要用另外一个Linux系统启动，挂载升级失败的根文件系统，把原根文件系统的/lib/tls/下的链接全部改为指向2.6版本的库文件，具体就是/lib/tls/libc.so.6，/lib/tls/libm.so.6， /lib/tls/libpthread.so.0和/lib/tls/librt.so.1这4个软链接分别指向libc-2.6.so, libm-2.6.so，libpthread-2.6.so和librt-2.6.so。libthread_db.so.1仍然是指向 libthread_db-1.0.so，但这个时候/lib/libthread_db-1.0.so已经是Glibc2.6版本的了，原 /lib/tls/libthread_db-1.0.so必须被替换为Glibc2.6版本的libthread_db-1.0.so。

笔者使用Knoppix 5.0.1 Live CD启动计算机，启动后，打开一个控制台，执行"su"命令切换为root，执行以下命令：

# cd /mnt
# mkdir m1
# mount -t xfs /dev/hda5 /mnt/m1
# cd /mnt/m1/lib/tls
# cp -f ../libthread_db-1.0.so .
# cp ../libc-2.6.so .
# cp ../libm-2.6.so .
# cp ../libpthread-2.6.so .
# cp ../librt-2.6.so .
# ln -sf libc-2.6.so libc.so.6
# ln -sf libm-2.6.so libm.so.6
# ln -sf libpthread-2.6.so libpthread.so.0
# ln -sf librt-2.6.so librt.so.1

上述命令就是把原根文件系统/lib/下的 libc-2.6.so, libm-2.6.so，libpthread-2.6.so和librt-2.6.so拷贝到/lib/tls/下，并把 /lib/tls/libc.so.6，/lib/tls/libm.so.6，/lib/tls/libpthread.so.0和 /lib/tls/librt.so.1这4个软链接从原来指向2.3.5版本的库文件改为指向最新的2.6版本的库文件。原 /lib/tls/libthread_db-1.0.so下的文件被/lib/libthread_db-1.0.so替换。

4.2 第二次make install

修改了/lib/tls/下的链接和文件后，就可以重新启动计算机，进入原Linux系统，这次将会正常启动，登陆后，执行Coreutils的命令，例如 ls，已经不会出现"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息。由于Glibc2.6没有彻底安装完毕，我们还要重新执行一次make install：

$ cd ~/build
$ cd glibc-2.6-build
$ su
# make install

这次make install将不会出现错误，如果安装成功，到最后会有以下信息提示：

Your new glibc installation seems to be ok.
make[1]: Leaving directory `/home/xyz/build/glibc-2.6'

执行/lib/libc.so.6查看Glibc的版本：

$ /lib/libc.so.6 
GNU C Library stable release version 2.6, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0).
Compiled on a Linux >>2.6.12-12mdk<< system on 2007-05-26.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
For bug reporting instructions, please see:
<[url]http://www.gnu.org/software/libc/bugs.html>.[/url]

执行chk_lib_v：

$ ./chk_lib_v 
2.6

这都表明当前系统的动态库已经使用了Glibc2.6。

如果把/lib/tls/下的链接改为指向2.6版本的库文件后，重新启动计算机仍然无法进入原Linux系统，就说明升级Glibc失败，只能再次使用另外一个Linux系统启动，恢复原系统的Glibc为原来的版本，请参考3.3节。

4.3 安装时区和地区数据库

虽然现在系统已经使用Glibc2.6，但是在X Window下，使用fcitx中文输入法的用户会发现按下ctrl+space不会弹出中文输入框。这是因为新的Glibc2.6还没安装时区和地区数据库。执行以下命令：

$ cd ~/build
$ cd glibc-2.6-build
$ su
# make localedata/install-locales

上述命令将会在/usr/lib/locale/下生成一个名为"locale-archive"的文件。重新启动X Window, 按下ctrl+space就可以调出中文输入框并输入中文了。

至此，升级Glibc完毕。笔者在升级到了Glibc2.6的Linux系统上使用了VMware，Openoffice，Mplayer，Skype， Firefox，Thunderbird，Vim，Fcitx等一系列软件一段时间，未发现由于升级了Glibc而导致的错误出现。

回到Glibc2.3.5 成功升级后，想在Glibc2.6和原来的Glibc2.3.5之间切换是很容易的。因为安装前对Glibc2.3.5的重要目录进行了备份，只需使用另外一个Linux启动，挂载原Linux的根文件系统，把升级前备份好的/lib.2.3.5等目录的名字改为/lib等原来的名字即可。

使用Knoppix 5.0.1 Live CD启动，打开一个控制台，执行"su"命令切换为root，执行以下命令：

# cd /mnt
# mkdir m1
# mount -t xfs /dev/hda5 /mnt/m1
# cd /mnt/m1
# mv lib lib.2.6
# mv lib.2.3.5 lib
# cd usr
# mv lib lib.2.6
# mv bin bin.2.6
# mv sbin sbin.2.6
# mv include include.2.6
# mv lib.2.3.5 lib
# mv bin.2.3.5 bin
# mv sbin.2.3.5 sbin
# mv include.2.3.5 include

重新启动，系统将会使用原来的Glibc2.3.5，Glibc2.6的目录备份为原目录名后加.2.6后缀。

总结

使用源代码升级Glibc，做好升级前的准备是最重要的。首先要准备好另外一个可以启动的，能挂载原根文件系统的Linux系统。其次是对/lib， /usr/lib，/usr/include，/usr/sbin，/usr/bin等目录进行备份。成功升级后，可以在高低两个版本的Glibc之间自由切换。

升级前只要做好上述两个准备，升级系统的Glibc是安全的。

由于不同的Linux发行版的系统环境不一样，因此使用源代码升级Glibc的过程可能会有差异，为了成功升级，读者必须在升级过程中根据自己的系统的实际情况作相应的调整。

参考资料