再探编译源码升级 glibc 的问题

小弟屡战屡败。。。屡败屡战多次，不论如何

用这些方法：
http://www.linuxsir.org/bbs/showthread.php?t=164968

http://www.linuxsir.org/bbs/showthread.php?t=228819

什麽 glibc-howto 或者 static link 的 toolchain 等方式都是无功而还，出奇地，用 paco 来简接安装却是无往而不利的（虽然只有两次）
http://www.linuxsir.org/bbs/showthread.php?t=295562

还看各大发行版都能随心所欲地用二进包升级，Gentoo 又能通过 ebuild 无痛地源码编译安装升级 glibc，似乎都有一个同通点就是不能直接用 make install，但为何直接调用不行，简接安装又行呢？不解。。。郁闷中！

作者: d00m3d 发布时间: 2007-07-01

我这里可以的。不过以前在Magic Linux上升级，总是段错误，把系统都搞崩了。

作者: hohoxu_hao115 发布时间: 2007-07-02

今天尝试把系统的 glibc 由 2.5 升级为 2.6，记得手册曾经提及 /usr/include 里的头文件必定是用於编译 glibc 的头文件

引自 http://www.linuxfromscratch.org/lfs/...08/kernel.html

引用:

Warning

The headers in the system's include directory should always be the ones against which Glibc was compiled, that is, the sanitised headers from this Linux kernel tarball. Therefore, they should never be replaced by either the raw kernel headers or any other kernel sanitized headers.

於是顺手把老旧的 linux-libc-headers 换成 Linux API Headers，由内核源码提取出来

编译完成後依旧利用 paco 安装，又是顺利的。

paco 这发明实在太伟大了：）

By the way, 新版 paco-2.x 很麻烦，要特别的依赖，还是用 1.2.10 算了

作者: d00m3d 发布时间: 2007-08-14

doom3d老兄不如参考一下我做的Olive安装软件包的脚本吧,也是支持glibc升级的,不妨试一下?

作者: youbest 发布时间: 2007-08-18

是啊！

这个都忘记了，该打

作者: d00m3d 发布时间: 2007-08-18

其实 glibc 也是一个软件，如果我们以一般的软件去对待，就没啥问题了。

比如 glibc 就是 readline，那么 bash 编译的时候，连接了一个 readline A，那么如果我们安装了 readline B 的话，bash是否需要重新编译呢？那就要看 readline 的 ABI等是否有改变。同理，glibc 也是这个样子，我觉得其实没啥区别的。

至于为啥不能直接 make install 的原因，我觉得主要是因为怕安装的时候出错，那么就造成了系统的 glibc 不统一，上不上下不下的（咬苹果你最怕见到几条虫？答案：半条。）。再用 readline 来做例子，就是如果 readline 升级错误的话，你的bash 就死掉了，一旦退出就不能再进入（当前的是在内存里边，所以不受影响）。

作者: 晨想发布时间: 2007-08-18

这个比喻不错，也许解释了不能直接 make install 的原因，那麽何以简接安装又行呢？是否绕过了些什麽？

作者: d00m3d 发布时间: 2007-08-18

引用:

作者: youbest

doom3d老兄不如参考一下我做的Olive安装软件包的脚本吧,也是支持glibc升级的,不妨试一下?

youbest 不如讲解一下你的脚本是怎样运作的

作者: d00m3d 发布时间: 2007-08-18

引用:

作者: d00m3d

这个比喻不错，也许解释了不能直接 make install 的原因，那麽何以简接安装又行呢？是否绕过了些什麽？

间接安装是什么意思？拷贝么？一般来说，一个 cp 命令是不会被中断，我想是这个原因吧。

作者: 晨想发布时间: 2007-08-18

make install 一般就是根据 Makefile 或 makefile 预先设定好的脚本去调用 cp 来拷贝，但以前也讨论过，就连 static link 的 cp 也会出问题才费解

间接安装是指像 paco 般的安装，它安装前栏截了系统的信息，记录了安装位置等，之後才 cp，这样却无往而不利，不解

作者: d00m3d 发布时间: 2007-08-21

我不知道你说的现象是否准确。我推测：

直接安装，如 make install，每次 cp/install 都是一次新的调用，所以一旦glibc出错 make install 就继续不下去了，马上就出错。

而间谍安装，如 paco 安装，就是先调用 paco，至于paco是如何调用的 cp/install 这类命令，我就不知道了；也许甚至是不用这些命令，而是用paco 自己的内部命令/函数完成。只是这么估计，不然也应该绕不过上边提到的问题的。

作者: 晨想发布时间: 2007-08-22

可是 static link 的 cp 也不行呀，也许就是 glibc 崩掉後就连调用 cp 的函数（能力）也没有了。。。

作者: d00m3d 发布时间: 2007-08-22

问题是，你确定你用的是 static link 的 cp 么？
是不是你有东西没做好？或者你认为的 static link本身不是 static link 的？因为理由上好像说不通，当然，也许是我有东西没考虑到：（。

作者: 晨想发布时间: 2007-08-23

都是哪个时候信了哪些 xxxx-howto 的鬼主意用 static 的 make、coreutils、tar、bash 等来装，总之都是没有用的

http://www.ibiblio.org/pub/Linux/doc...all-HOWTO.html

作者: d00m3d 发布时间: 2007-08-23

信息也许有点老了，这个方法也许不是个好方法，太麻烦，也没必要。

作者: 晨想发布时间: 2007-08-24

其实升级GLIBC还是比较容易的。。。。按照LFSBOOK来了就可以了，直接走第二遍的GLIBC，在操作之前把ld.so.conf关掉，等全部操作完成后再打开

作者: pinkme005 发布时间: 2007-08-27

最初就是看了兄台的帖子行事的，可是却屡战屡败。。。

能再详细一点说说你现在的升级过程吗？

作者: d00m3d 发布时间: 2007-08-27

楼主是说直接安装不可以,用paco就可以么?如果不用包管理,楼主是怎么删除前一个版本的文件的?

作者: LanEast 发布时间: 2007-08-29

我从来都是先
make install install_root=/other/dir
然后
mv -f /other/dir/lib/* /lib/
mv -f /other/dir/sbin/* /sbin/
......
就OK，从来不会出问题
注意，是mv而不是cp
-----------------------
直接 make install 貌似不行，执行时间太长，夜长梦多....

作者: csfrank 发布时间: 2007-08-29

金兄用这一招装过哪些版本？

作者: d00m3d 发布时间: 2007-08-29

我一直用2.3.6，这么看来我这个不能算升级，只能算重新覆盖
只是编译参数不同/使用不同的编译器的差别
但是就在这种情况下直接 make install 也会失败

而如果glibc的版本不同，我想绝对不可以这么简单的直接覆盖
发行版能够升级glibc应当也是顺着依赖关系升级了一大批其他部件

作者: csfrank 发布时间: 2007-08-29

哪麽下次升级时去试试金兄的方法

作者: d00m3d 发布时间: 2007-08-29

对了，无论如何，尽可能在升级glibc的时候关闭一切可能运行的其他进程
最好只有一个shell在运行

作者: csfrank 发布时间: 2007-08-29

刚我试了一下，直接make install就可以。。-_-U
用的是我很久之前备份的系统，glibc是2.3.6的，然后升级到2.5.1
直接编译，然后make install，再make localedata/install-locales
cp -v --remove-destination /usr/share/zoneinfo/Asia/Shanghai /etc/localtimel
没有使用paco
然后再到/lib下面把所有*2.3.6*给rm了
然后ldconfig了一下
用paco查看了一下“前一个版本”的glibc中其它文件的日期，就只有/usr/share/locale下面几个文件和/etc/ld.so.conf和nsswitch.conf是旧文件了

系统一样没有出问题

作者: LanEast 发布时间: 2007-08-29

怎麽我直接 make install 老是会死？

不幸。。。

作者: d00m3d 发布时间: 2007-08-29

老大，先确定不是硬件问题～～。；）

作者: 晨想发布时间: 2007-08-31

为何联想到是硬件问题呢？

作者: d00m3d 发布时间: 2007-08-31

这个，把最没可能先排除么～～。。。

作者: 晨想发布时间: 2007-09-01

怎么会在MAKE INSTALL时死掉呢。。。可能是硬件问题。。。如果在MAKE INSTALL出现错误异常终止，那是方法问题

作者: pinkme005 发布时间: 2007-10-05

引用:

作者: csfrank

我从来都是先
make install install_root=/other/dir
然后
mv -f /other/dir/lib/* /lib/
mv -f /other/dir/sbin/* /sbin/
......
就OK，从来不会出问题
注意，是mv而不是cp
-----------------------
直接 make install 貌似不行，执行时间太长，夜长梦多....

我试过了,用cp就完蛋了,但是用mv就没事,然后看glibc安装的时候的日志,glibc本身的安装用的也是mv的方法
这是其中的一部分

引用:

/usr/bin/install -c /home/lane/glibc-build/elf/ld.so /lib/ld-2.7.so.new
mv -f /lib/ld-2.7.so.new /lib/ld-2.7.so

上面是在我真实的机器上从glibc-2.6.1升级到2.7的时候的log文件里面的一部分

所以我觉得mv应该是安全的

作者: LanEast 发布时间: 2007-12-12

莫非 glibc 的 developers 也知道 cp 会完蛋，用 mv 才行？

但是为什麽 mv 可以，cp 又不行呢？

作者: d00m3d 发布时间: 2007-12-13

slackware用了另一种方法,我试了,在slackware上可以,我拿到LFS上用就不行.
不过slackware的方法在slackware上似乎也有出错信息,只不过不显示

作者: LanEast 发布时间: 2007-12-16

好奇心驱使，请 LanEast 兄说说 Slackware 的方法有啥不同吧

作者: d00m3d 发布时间: 2007-12-16

代码:

if [ -r /proc/ksyms ]; then
 echo "FATAL: you need to be running a 2.6.x kernel in order to upgrade"
 echo "to this version of glibc."
 echo
 sleep 999
 exit 1
fi

# Next, stop using the /lib/ntpl libraries. These are now obsolete and
# will break the installation if present:
if [ -d lib/tls ]; then
 mkdir -p lib/obsolete
 mv lib/tls lib/obsolete
fi
if [ -x sbin/ldconfig ]; then
 sbin/ldconfig -r .
fi

# Install NPTL glibc libraries:
if [ -x /sbin/ldconfig -a -d lib/incoming ]; then # swap on the fly
 # First create copies of the incoming libraries:
 ( cd lib/incoming
 for file in * ; do
 if [ ! -r ../${file}.incoming ]; then
 cp -a $file ../${file}.incoming
 fi
 done
 )
 # Then switch to them all at once:
 /sbin/ldconfig -l lib/*.incoming 2> /dev/null
 # Finally, rename them and clean up:
 ( cd lib
 for file in *.incoming ; do
 rm -f `basename $file .incoming`
 cp -a $file `basename $file .incoming`
 /sbin/ldconfig -l `basename $file .incoming`
 rm -f $file
 done
 )
else # no ldconfig? Good, it's safe to just jam it on home (and make links below):
 ( cd lib/incoming
 for file in * ; do
 cp -a $file ..
 done
 )
fi
# Now, get rid of the temporary directory:
rm -rf lib/incoming
# Done installing NPTL glibc libraries.

这个是slackware的glibc-solibs-2.5-i486-4.tgz的安装脚本中的关键部分
我直接把

代码:

if [ -x /sbin/ldconfig -a -d lib/incoming ]; then # swap on the fly
 # First create copies of the incoming libraries:
 ( cd lib/incoming
 for file in * ; do
 if [ ! -r ../${file}.incoming ]; then
 cp -a $file ../${file}.incoming
 fi
 done
 )
 # Then switch to them all at once:
 /sbin/ldconfig -l lib/*.incoming 2> /dev/null
 # Finally, rename them and clean up:
 ( cd lib
 for file in *.incoming ; do
 rm -f `basename $file .incoming`
 cp -a $file `basename $file .incoming`
 /sbin/ldconfig -l `basename $file .incoming`
 rm -f $file
 done
 )
else # no ldconfig? Good, it's safe to just jam it on home (and make links below):
 ( cd lib/incoming
 for file in * ; do
 cp -a $file ..
 done
 )
fi

存成一个脚本使用,比直接cp要好一些,cp一用就挂,这个脚本用了至少shell不挂,但是其它的命令就用不了了
在slackware中使用,出现了segment fault的提示,但是没什么影响

作者: LanEast 发布时间: 2007-12-17

看大家讨论得热烈，对这种重要问题，我也来凑个热闹吧。

1。关于 mv 和 cp的问题，我觉得还是有区别的：因为直觉上mv只是修改了目录结构，而cp需要完整的文件操作；或许在 glibc更新过程中进行文件操作会破坏系统的完整性；

2。最关键的问题是，在单纯升级 glic 后，是否会有比较核心的程序崩溃？是否需要立刻重新编译内核等等，这个不知道是否有现成的资料？我觉得如果解决了这个问题，对LFS的应用会更有意义。

作者: linux001 发布时间: 2007-12-17

1. 不详

2. 这要看新旧旧版之间有哪些地方不同，多数情况下是向下兼容的，问题应该不大，但也有可能某些程序会有问题，这不奇怪。

内核虽然也是 C 程序，但出问题的机会并不大，否则 glibc 是不会 release 出来的

资料方面，源码包里的文档应该很详细了

作者: d00m3d 发布时间: 2007-12-18

引用:

作者: linux001

看大家讨论得热烈，对这种重要问题，我也来凑个热闹吧。

1。关于 mv 和 cp的问题，我觉得还是有区别的：因为直觉上mv只是修改了目录结构，而cp需要完整的文件操作；或许在 glibc更新过程中进行文件操作会破坏系统的完整性；

2。最关键的问题是，在单纯升级 glic 后，是否会有比较核心的程序崩溃？是否需要立刻重新编译内核等等，这个不知道是否有现成的资料？我觉得如果解决了这个问题，对LFS的应用会更有意义。

1.这个不太清楚,不过感觉有点像这个意思-_-U

2.升级过glibc,但是升级完了之后就很少用升级之后的系统,所以稳定性就不太清楚了.另外,内核应该不依赖glibc的吧?

作者: LanEast 发布时间: 2007-12-19