泉州市网站建设_网站建设公司_Node.js_seo优化

原因

VS Code升级1.85以上后，隐性升级了捆绑的node版本，vscode-server的node依赖于GLIBC_2.28（使用旧版本等于丧失新功能使用权，而且设置也可能无法同步）

常见报错

• sh: 1: /scripts/wslServer.sh: not found

升级后，由于关闭了wsl自动挂载，需把对应部分全删去（可以做好部分）

vim /etc/wsl.conf

• /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found

node需要GLIBC_2.28支持，而Ubuntu 18.04最高支持GLIBC_2.27

GLIBC

支持的 glibc 版本”就是仓库里 libc6 软件包对应的版本

查看系统对应版本

ldd = “list dynamic dependencies”

ldd --version

查看还可安装版本

apt-cache policy libc6

查看libc 支持的最高/最低版本

strings /lib/x86_64-linux-gnu/libc.so.6 | grep GLIBC_

查看自装的glibc-2.28

strings /opt/glibc-2.28/lib/libc.so.6 | grep GLIBC_

strings /opt/glibc-2.28/lib/libc.so.6 | grep -E '^GLIBC_'

Node.js(扩展)

node=Node.js 运行时主程序（ELF 可执行）

作用：把 JavaScript 搬到服务器、命令行、桌面” 的 跨平台运行时 + 海量生态

nvm 管 Node 版本 → Node 自带 npm → npm 管 JS 包

安装指定版本node

nvm install 20

查看已安装node版本

nvm ls

切换node版本

nvm use 20.0.0

卸载node版本

nvm uninstall 18.10.8

解决办法

// 编译并覆盖安装glibc（libc6），否则导致系统异常崩溃

让VS Code 的远程连接node脱离系统 glibc，指向自定义 GLIBC-2.28

手动编译GLIBC-2.28

// 自定义目录保存源码 mkdir ~/lib/glibc-2.28/src/ cd ~/lib/glibc-2.28/src/ //下载源码 wget 'https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.gz' tar xzf glibc-2.28.tar.gz // 必须指定prefix，作用就是“告诉构建系统：安装时把文件放到哪里” mkdir glibc-2.28-build cd glibc-2.28-build ../glibc-2.28/configure --prefix=/opt/glibc-2.28 // 编译源码 make // 安装到指定目录 sudo make install

prefix：

不会影响系统/lib/x86_64-linux-gnu/libc.so.6，也不会自动被任何程序找到；
谁想用，就必须手动指定

安装之后得到

/opt/glibc-2.28/lib/libc.so.6 /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 /opt/glibc-2.28/include/...

修改node

进入报错目录下的node节点

~/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node

做好node备份

cp node node.bak

把node链接到我们安装的glibc-2.28上

按其它友友们的说下，以下任选一行，即可VS远程即可正常

• 方法一

patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu node

• 方法二

patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib:/usr/lib/x86_64-linux-gnu --force-rpath node

VS Code 用的 node 没走你的特制 ld.so，于是找不到libgcc_s.so.1

~/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory

比较方法一，其搜库路径是先 2.28 → 再系统 /lib → 再 /usr/lib
缺失了系统/lib，加上即可

--force-rpath不建议使用，“强行写老段”——优先级更高、无法被环境变量覆盖、已过时；无特殊兼容性需求就别加。

patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu --force-rpath node

方法三

若以上方法还是不行

直接在终端里生成一个小脚本，把原 node 二进制换成一个 shell wrapper

这个方法虽然能连上，但vs的功能基本上都用不了，“自废武功”

wrapper 脚本就是“壳”脚本——本身不是真正的可执行文件，但同名同路径，先被系统调到，内部再帮你把真实程序拉起来，顺便偷偷加点料（比如换 glibc、加环境变量、改参数等）

cat > /home/chenkang/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node <<'EOF' #!/bin/bash exec /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.28/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu /home/chenkang/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node.real "$@" EOF chmod +x /home/chenkang/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node

解析

• ld-linux-x86-64.so.2

ld.so 就是Linux 的“动态链接加载器”（/lib*/ld-linux*.so.2），内核 execve 任何动态链接 ELF 时第一个被拉进内存的程序——负责把可执行文件和所有 .so 库真正拼接成可运行进程，然后才把控制权交给你的 main。

• patchelf 改 interpreter/rpath≈ 给自家车库装了自动门，车一靠近就自己开。

--set-rpath：按顺序搜库，把搜库路径焊进文件里，一次修改永久生效。

--set-interpreter：改写 ELF 可执行文件“解释器”路径，谁运行 node 都会先加载你指定的 ld.so

• exec + --library-path≈ 每次出门都手动打一次网约车；

--library-path：手动选库路径开关，它只在那一次启动生效，不会写进可执行文件

验证

ldd node就是 "让 ld.so 预演一遍加载过程”，把最终选中的库路径逐行打印出来"，用来快速判断 node 实际会吃哪份 glibc

修改node链接前

修改node链接后