标签: glibc

如何修复此错误：

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

平台：

Linux alef 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux

我想根据 RedHat 更新 glibc：https : //rhn.redhat.com/errata/RHSA-2015-0090.html

glibc 升级后是否需要重启服务器？

我偶然发现了一个名为的文件ld.so.preload，但找不到它的任何实际用途。它与 env 变量有关LD_PRELOAD吗？

假设一组定制的gcc/glibc/binutils都在$prefix（例如/home/user/path）

我想要：

1. gcc寻找图书馆$prefix/lib64而不是/lib64
2. gcc寻找标题$prefix/include而不是/include
3. 在使用$prefix/lib64/ld-linux-x86-64.so.2作为（硬编码）装载机路径，而不是/lib64/ld-linux-x86-64.so.2
4. 动态加载器来查找共享库$prefix/lib64而不是/lib64

我应该如何配置构建？我需要修改gcc's specs 文件或做其他事情吗？

假设我有一个程序依赖于较新的 glibc 版本，该版本在系统中通过包不可用。它给出：

version `GLIBC_2.xxx' not found

一种解决方案是使用 glibc 静态编译二进制文件。

另一种被许多人认为“不安全”的解决方案是放置更新的libc.so.6而不是操作系统提供的。

如果包含先前的 ABI 端点，那么第二个解决方案究竟有多不安全或不是一个坏主意libc.so.6？

例如，如果我运行，strings /usr/lib/libc.so.6 | grep --perl-regexp "^GLIBC_"我可以看到很多 ABI 版本，例如：

...
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
...

因此，如果我使用其中libc.so.6包含其他glibc ABI 版本的较新版本覆盖，它如何破坏旧应用程序或导致系统损坏？

或者不是……？:)