如何升级libc.so.6以及升级后引发的灾难

什么是libc/glibc?,他们有啥用？

不知道的话，你可以点右上角的×了，你还是先思考一下为什么要升级？一定要升级吗？没别的办法了？

glibc是GNU发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。

首先说一下我为什么会去升级glibc，大概就是年少无知吧。。。

硬件环境：RK3399

软件环境：aarch64 centos7.9  libc  2.17 updateEngine

过程：

我把的centos7.9移植rk3399上，但是由于需要使用rk提供的updateEngine做ota升级，编译sdk后生成updateEngine工具，拷贝到centos后无法运行，缺少libpng.so,然后拷贝libpng.so到系统下，发现libc.so等等库版本太低了，于是我第一的想法就是解决版本库太低的问题，就开始了我的升级之路了。

下载链接：http://ftp.gnu.org/gnu/glibc/

编译步骤：1../configure 2.make 3.make install,报错的话就google一下就ok，都能解决

参考一下：https://blog.csdn.net/officercat/article/details/39520227

升级完成：updateEngine可以正常使用了，但是麻烦事也来了，测试那边各种提issue，hwclock 段错误，lspci 重定向出错，lspci -vvv | grep失败也报错，yum update系统宕机，yum卸载软件会把其他系统工具莫名奇妙卸载等等。

解决问题：我发现旧版本的centos是不存在这个问题，然后hwclock和 lspci等软件工具的问题可以重新编译即可解决，但是yum update系统崩溃（因为检测到各种lib和source依赖之间不对，yum update会进行大量的更新，更新完就挂了）。由于更新了系统不稳定性太大了，最近决定还原回去，问题解决。

回到原点：怎么解决updateEngine的问题呢？

updateEngine编译环境：Ubuntu18.04 ，rk3399 sdk

解决方案：

1.使用centos的lib编译updateEngine,只要它不用高版本libc的特性就好，修改Makefile。

2.静态编译，静态编译就是编译器在编译可执行文件的时候,将可执行文件需要调用的对应动态链接库(.so)中的部分提取出来,链接到可执行文件中去,使可执行文件在运行的时候不依赖于动态链接库。修改Makefile

我用的就是第三种

3.在我准备修改Makefile的时候我发现了updateEngine有个No_UI的变量，噢噢噢，然后再仔细看一下libpng库是updateENgine UI界面的时候调用，我们并不需要，然后修改一下配置文件去掉，解决了。

总结:centos为什么系统库都这么老了，就是为了稳定性，更新有风险，请谨慎。现在centos8以上的系统库都已经比较新了，需要的话可以换到centos8以上的版本