注意更新系统库存在一定的风险, 请谨慎操作
默认的CentOs6.5 glibc版本最高为2.12, 而在进行Nodejs开发时项目所依赖的包往往需要更高版本的glibc库支持, 因此在不升级系统的前提下, 需要主动更新系统glibc库. 一般遇到错误
libc.so.6: version GLIBC_2.14 not found
时表示需要对glibc进行升级了.
glibc升级导致系统段错误问题解决方案
统：阿里云ECS CentOS6.5 当前GLIBC版本：2.12 准备升级GLIBC版本：2.19在升级Glibc至2.19时，遇到了系统段错误问题，以下为问题解决步骤。 一、Glibc介绍Glibc是GNU发布的libc库，是Linux系统中最底层的API，几乎任何运行库都会依赖于Glibc。 它除了封装Linux操作系统提供的系统服务外，还提供了许多必要的功能服务实现。 Glibc和内核不是同时开发的，因此需要兼容不同版本的内核，而内核也需要兼容不同版本的Glibc，这导致了双方都背负了太多的历史负担。 二、升级Glibc原因当前ECS上需要安装Nginx 1.15.9，由于编译的Nginx版本，发现Glibc库版本可能过低，为了确保Nginx正常运行，决定升级Glibc至2.19版本。 三、问题出现原因升级并编译Glibc后，需要在系统中指定库文件的路径，添加到/etc/.d/文件中，然后使用ldconfig -v将库文件生效加载，再将库文件中的.6做软连接至系统识别的路径。 然而，在这之后，无论执行任何命令，系统都显示段错误。 四、解决方案为了解决段错误问题，需要在其他相同配置的机器下，查看/lib64/.6文件，发现.6实际上是一个软连接文件。 这时，需要手动使用ldconfig链接原来的SO文件。 完成此操作后，系统恢复正常，不再显示段错误。 总结：Glibc是系统底层依赖的文件，自行编译升级可能会导致与内核版本不兼容的问题。 因此，建议使用yum进行升级，避免自行编译带来的麻烦。 在寻求技术提升的同时，欢迎工作一到五年的Java工程师加入Java程序员开发群。 群内提供免费的Java架构学习资料，包括高可用、高并发、高性能及分布式、JVM性能调优、Spring源码、MyBatis、Netty、Redis、Kafka、MySQL、Zookeeper、TOMCAT、Docker、Dubbo、Nginx等多个知识点的学习资源。 利用好每一分每一秒的时间，不断学习提升自己，避免以“没有时间”为借口掩饰懒惰。 趁年轻，努力学习，给未来的自己一个交代。
centos6.5安装wps提示缺libc.so.6(GLIBC_2.15)(64bit),怎办?
1.试图运行程序，提示.6: version `GLIBC_2.14 not found,原因是系统的glibc版本太低，软件编译时使用了较高版本的glibc引起的：
[ghui@StuOS bin]$ pwd
/var/VMdisks/cross/mingw32/bin
[ghui@StuOS bin]$ ls
[ghui@StuOS bin]$ ./qmake
./qmake: /lib64/.6: version `GLIBC_2.14 not found (required by ./qmake)
2.查看系统glibc支持的版本：
[ghui@StuOS bin]$ strings /lib64/.6 |grep GLIBC_
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_PRIVATE
[ghui@StuOS bin]$ RPM -qa |grep glibc
6_3.6.x86_64
6_3.6.x86_64
6_3.6.x86_64
6_3.6.x86_64
6_3.6.i686
6_3.6.i686
6_3.6.i686
6_3.6.x86_64
3.可以看到最高只支持2.12版本，所以考虑编译解决这个问题：
a. 到下载最新版本，我这里下载了 这个版本，解压到任意目录准备编译
b.这里解压到/var/VMdisks/glibc-2.14/
[ghui@StuOS bin]$ cd /var/VMdisks/glibc-2.14/
[ghui@StuOS glibc-2.14]$ pwd
/var/VMdisks/glibc-2.14
[ghui@StuOS glibc-2.14]$ ls
aclocal.m4 -abis resource
aoutconfigure libidn rt
libio Rules
assert conformLICENSESscripts
CONFORMANCElocale setjmp
bitsCOPYINGlocaledata shadow
shlib-versions
build machsignal
CANCEL-FCT-WAIVEcrypt Makeconfig SOCket
CANCEL-FILE-WAIVE csuMakefilesoft-fp
catgetsctype -common
ChangeLog debug Makerules stdlib
ChangeLog.1direntmalloc streams
ChangeLog.10dlfcn manual string
ChangeLog.11elfmathsunrpc
miscsysdeps
NAMESPACE sysvipc
ChangeLog.14FAQNEWStermios
-skeleton.c
ChangeLog.16gmon NOTES time
ChangeLog.17gnulibnptltimezone
ChangeLog.2grpnptl_.c
ChangeLog.3gshadownscdversion.h
ChangeLog.5hurd wcsmbs
ChangeLog.6iconv po wctype
ChangeLog.7iconvdata posix WUR-REPORT
ChangeLog.8includePROJECTS
ChangeLog.9inet pwd
confINSTALLREADME
c.在glibc源码目录建立构建目录，并cd进入构建目录
[ghui@StuOS glibc-2.14]$ mkdir build
[ghui@StuOS glibc-2.14]$ cd build
d.运行configure配置，make && sudo make install
[ghui@StuOS build]$ ../configure --prefix=/opt/glibc-2.14
[ghui@StuOS build]$ make -j4
[ghui@StuOS build]$ sudo make install
[sudo] password for ghui:
4.临时修改环境变量
[ghui@StuOS bin]$ export LD_LIBRARY_PATH=/opt/glibc-2.14/lib:$LD_LIBRARY_PATH
[ghui@StuOS glibc-2.14]$ cd /var/VMdisks/cross/mingw32/bin/
[ghui@StuOS bin]$ ./qmake
Usage: ./qmake [mode] [options] [files]
QMake has two modes, one mode for generating project files based on
some heuristics, and the other for generating makefiles. Normally you
shouldnt need to specify a mode, as makefile generation is the DEFault
mode for qmake, but you may use this to test qmake on an existing project
linux ld.so.preload机制解析
解决了一个问题，如果对linux selinux有所了解，应能立即看出原因，但既然已分析，记录下来，也算学习与提升的过程。 问题出现在一个名为hook_的文件，利用/etc/配置，使每个进程加载此，实现特定目的。 在centos7上无问题，但centos6.5上配置后，ssh连接失败，手动重启sshd服务后报错。 初步判断为权限问题，但具体原因需从代码层面分析。 查看glibc版本为2.12，下载同版本源码，打开代码搜索cannot be preloaded，找到dl_catch_error函数报错点，但未打印errstring，仅打印笼统错误信息。 由于无法直接分析dl_catch_error函数，转向了解配置的工作机制。 进程创建通过fork和execve实现，fork调用sys_fork系统调用，复制父进程信息，设置内核栈，返回后调用execve。 execve调用sys_execve系统调用，主要功能为加载可执行的ELF文件。 load_elf_binary解析ELF文件，包含头部信息、Program header table和section信息等。 使用readelf查看可执行程序内容，重点关注INTERP和LOAD类型。 INTERP指定动态链接器路径，常为/lib64/.2；LOAD段包含要加载到内存运行的内容。 load_elf_binary解析INTERP内容，加载至地址空间。 通过readelf查看路径值，接着解析加载，最终返回值+interp_elf_ex.e_entry得到用户态入口虚拟地址。 在用户态，_start作为总入口，调用_dl_start，最终调用dl_main加载依赖文件。 dl_main在加载前，判断是否需要PRELOAD的文件，即/etc/配置的文件。 在2.12版本中，此路径由glibc代码写死。 解析/etc/，一行行读取，#号开头的行忽略，其余行调用do_preload加载文件。 在do_preload中，实际调用dl_catch_error报错，进一步分析map_doit、open_verify等函数，发现__open打开文件时即报错。 问题与sys_open源码中selinux权限检查相关。 关闭selinux后，问题解决。 如果使用selinux，可将文件放置于/lib64目录下，同样可以加载。
发表评论