背景就是上一篇文章提到的,部署gitbook这个文档中心的话,是需要先安装node,然后,如果你的node版本过高的话,一般会报错,此时,网上很多文章就是降node版本解决,但其实用高版本也是有办法的,只是麻烦点,要改改代码;但是,我下载了高版本的node安装时,发现在centos7上还装不了,可谓一波未平一波又起。
报错的nodejs版本:v18,我这边具体的是node-v18.18.2-linux-x64.tar.xz
服务器版本是centos 7.6,centos 7.9(两个都试了)
下面这个问题可以看下:
吵得还是挺厉害。我觉得也是比较坑的是,下载的时候,文档也没个提示,比如是否在centos7上可用,等到弄下来搞出一堆问题了上网去找才知道版本不兼容。
下面具体说下这个问题。
tar -xvf node-v18.18.2-linux-x64.tar.xz cd node-v18.18.2-linux-x64/ [root@VM-0-6-centos node-v18.18.2-linux-x64]# bin/node bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by bin/node) bin/node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by bin/node) bin/node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by bin/node) bin/node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by bin/node) bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by bin/node) bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bin/node)
这个报错,是这个意思,node在执行的时候,是依赖了一些动态库的,依赖了哪些呢:
[root@VM-0-6-centos node-v18.18.2-linux-x64]# ldd bin/node linux-vdso.so.1 => (0x00007fff34927000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fd57af20000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fd57ac19000) libm.so.6 => /lib64/libm.so.6 (0x00007fd57a917000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd57a701000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd57a4e5000) libc.so.6 => /lib64/libc.so.6 (0x00007fd57a117000) /lib64/ld-linux-x86-64.so.2 (0x00007fd57b124000)
在 => 这个符号左侧,就是依赖的动态库名字,右侧,就是根据这个名字,在环境变量LD_LIBRARY_PATH指定的路径下查找,最终解析到的动态库全路径。
那我们再来看第一行报错:
[root@VM-0-6-centos node-v18.18.2-linux-x64]# bin/node bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by bin/node)
/lib64/libm.so.6
这个是全路径,看起来找到了,但是还是报错,好像说要在GLIBC_2.27
这个版本没找到。
我们可以这样,在执行ldd
时打个详细日志:
[root@VM-0-6-centos]# ldd -v bin/node Version information: bin/node: ... libm.so.6 (GLIBC_2.27) => not found libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
看起来,它是找libm.so.6(GLIBC_2.27)没找到,但找到了libm.so.6 (GLIBC_2.2.5)。
这块其实是这样,内核提供给用户的是系统调用(system call),但是,在我们编写c语言代码时,一般不是直接去调用这些系统调用,而是会include一些头文件,如include <stdio.h>
,这些头文件算是接口,这些接口包括其实现,最终编译成二进制打成一个库,供用户使用。最早是标准的libc库,后来逐渐被glibc这个取代,glibc是GNU发布的libc库,官网:The GNU C Library- GNU Project - Free Software Foundation
这个glibc库,比如在我的centos7.6上,到底在啥位置呢?
我先看了下本机的glibc版本是2.17:
https://lindevs.com/check-glibc-version-in-linux 方法1: [root@VM-0-6-centos lib64]# ldd --version ldd (GNU libc) 2.17 方法2: [root@VM-0-6-centos lib64]# ldd `which cat` | grep libc libc.so.6 => /lib64/libc.so.6 (0x00007f27331c8000) [root@VM-0-6-centos lib64]# /lib64/libc.so.6 GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.
glibc一般也是有rpm包的,我在这个网站上找到了2.17版本的x86-64的glibc的包:
glibc-2.17-326.el7_9.x86_64 RPM
可以看到,它其实包含了非常多文件,其中就有/lib64/libm.so.6:
那我意思其实就是,/lib64/libm.so.6
就是glibc的一部分,那这个2.17版本的glibc,包含的/lib64/libm.so.6
报的这个错到底啥意思啊?
[root@VM-0-6-centos]# ldd -v bin/node Version information: bin/node: ... libm.so.6 (GLIBC_2.27) => not found libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
我找到了一个绝好的回答:
GLIBC_..., GLIBCXX_... etc. are version symbols, which are used in some libraries (including the GNU C library and the GCC libraries) to identify required versions and to manage backward compatibility. A binary (executable or library) will usually end up requiring multiple versions, based on the symbols it really uses from the target library. To satisfy the requirements of a given binary, you need to provide a library which supports all the required versions — i.e. a library matching at least the highest version symbol in the list of requirements.
翻译过来是,GLIBC_...
等GLIBCXX_...
是版本符号,在某些库(包括GNU C库和GCC库)中使用它们来标识所需的版本并管理向后兼容性。二进制文件(可执行文件或库)通常最终需要多个版本,具体取决于它实际使用的目标库中的符号。为了满足给定二进制文件的要求,您需要提供一个支持所有所需版本的库 -即至少匹配要求列表中最高版本符号的库。
The reason multiple versions can end up being required, is that each imported object (function etc.) can have a version, and a given binary can link against multiple versions across all the functions it uses.
翻译:最终可能需要多个版本的原因是每个导入的对象(函数等)都可以有一个版本,并且给定的二进制文件可以链接到它使用的所有函数的多个版本。
我这里也只截取了一部分,大家还是去看原文吧,反正意思就是,比如node这个程序,它就是会用到/lib64/libm.so.6
里面不同version symbol
的函数,你需要做的,就是满足它,否则,它就报错。
怎么满足它呢,就是把/lib64/libm.so.6
的版本升上去,直到包含GLIBC_2.27
这个version symbol。
那怎么才能升/lib64/libm.so.6
上去呢,那它既然是glibc的一部分,自然是只能整体升级glibc到指定版本,比如这里的GLIBC_2.27
。
这里参考了文章:
跟我遇到的坑差不多。文章里1、安装编译环境devtoolset-8
那部分应该不需要特别关注,我觉得也不用操作,因为这种偷懒方式安装的gcc,是解决不了node安装报错的问题的,往下看就知道了。
开始升级glibc,值得注意的是,大家最好是虚拟机、个人的云主机先玩一玩,不要拿着有其他人在用的环境搞这些,很容易把机器彻底搞到不能收场的地步;玩之前也记得备份,比如先复制一个虚拟机出去
慢的话,可以自己手动下载再上传 wget https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.gz --no-check-certificate tar -xzvf glibc-2.28.tar.gz cd glibc-2.28 mkdir build && cd build (一定要单独建个文件夹来build)
在编译开始前,修改 scripts/test-installation.pl 128行,增加 && $name ne "nss_test2" ,以避免编译错误 nss_test2报错,反正就是照着加一行。
接下来,是configure命令,尤其注意加--enable-obsolete-nsl,解决undefined reference to '_nsl_default_nss@GLIBC_PRIVATE'
,其他选项用他文章的也行,我的那个命令搞丢了(虚拟机后来搞别的搞坏了)
../configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin --enable-obsolete-nsl
然后就是:
make 或者 make -j4 (4个线程并发跑) 我记得我这边大概耗时半小时或一小时内,忘了,还是虚拟机这种性能差的 make install 检查里面的version symbol: strings /lib64/libc.so.6 | grep GLIBC
解决上面的问题后,继续执行node,还是报错,大概如下:
bin/node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by bin/node) bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by bin/node) bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bin/node)
查看这个里面的symbol version,最新到1.3.7,不满足1.3.9的要求: [root@VM-0-6-centos node-v18.18.2-linux-x64]# strings /lib64/libstdc++.so.6 |grep CXXABI_ CXXABI_1.3 CXXABI_1.3.1 CXXABI_1.3.2 CXXABI_1.3.3 CXXABI_1.3.4 CXXABI_1.3.5 CXXABI_1.3.6 CXXABI_1.3.7 最新到3.4.19,不满足3.4.20和3.4.21的要求: [root@VM-0-6-centos node-v18.18.2-linux-x64]# strings /lib64/libstdc++.so.6 |grep GLIBCXX ... GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19
按照官方文档来的:
安装gcc前,需要先安装依赖的gmp-devel mpfr-devel libmpc-devel,好多文章是说yum安装,我觉得也可以,但我就怕gcc版本和yum安装的这些依赖的版本不太匹配,建议还是按照如下方式来安装:
wget https://ftp.gnu.org/gnu/gcc/gcc-8.5.0/gcc-8.5.0.tar.gz --no-check-certificate cd gcc-8.5.0 ./contrib/download_prerequisites
这一步就会去下载对应的源码,需要互联网:
[root@VM-0-6-centos gcc-8.5.0]# ./contrib/download_prerequisites 2023-10-22 15:40:49 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2 [2383840] -> "./gmp-6.1.0.tar.bz2" [1] 2023-10-22 15:42:05 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-3.1.4.tar.bz2 [1279284] -> "./mpfr-3.1.4.tar.bz2" [1] 2023-10-22 15:42:42 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-1.0.3.tar.gz [669925] -> "./mpc-1.0.3.tar.gz" [1] 2023-10-22 15:44:31 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.18.tar.bz2 [1658291] -> "./isl-0.18.tar.bz2" [1] gmp-6.1.0.tar.bz2: OK mpfr-3.1.4.tar.bz2: OK mpc-1.0.3.tar.gz: OK isl-0.18.tar.bz2: OK All prerequisites downloaded successfully.
下完后,就保存到了当前目录下,几个tar包。
mkdir build cd build/ 我是不需要gcc支持编译go,需要的话,可以加上 ../configure --disable-multilib --enable-languages=c,c++ --prefix=$HOME/local 接下来就是make,我一开始求快,搞得是: nohup make -j4 2>&1 & 结果后面等了好久,报错了。。。抱着试试看心理,改成make,结果成功了 nohup make 2>&1 & tailf nohup.out make install export LD_LIBRARY_PATH=$HOME/local/lib64
这里这个make,要执行很久很久,反正我的云主机是这样,1核2g,cpu一直是100%,跑了2个半小时:
从4点20:
跑到6点40了:
搞完这些,再去用node,应该就没啥问题了。