我一次又一次地看到这样的问题：
这些是我们通常要推动的解决方案类型：
这真的是我们能做到的最好的吗？难道没有GLIBC的二进制版本，我们可以简单地将其解压缩到诸如之类的目录中/opt/myglibc，并设置$LD_LIBRARY_PATH或（任意）内容并运行我们想要的任何应用程序，而不会出现问题？
似乎需要GLIBC 2.14的应用程序，例如较新版本的Chrome（28+）？
注意：该线程标题为：Google Chrome 29已发布–在tecmint.com 上的RHEL / CentOS 6和Fedora 19/15上安装是最终使我想到这一点的原因。
Answers:
如果它用于其他任何库，但是glibc ...我想不可能有快速的方法，因为glibc是“硬编码”内容的地方。glibc适合您的内核版本，并且它的加载器是实际使用进行正确操作（TM）的实例LD_LIBRARY_PATH。
也许正确的方法是：
LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program`
不过，不确定是否可行。
无论如何，我认为使用替代的glibc需要一个尚未实现的框架，因为搜索路径有时是固定的，并且glibc总是必须适合您的OS /内核，因此不会有通用二进制文件IMO。Debian的多体系结构表明它并不简单，但是仍然可以做到。如果要除目标体系结构之外还有其他识别库的方法。
该网站给了我另一个相关主题：
在那里，可接受的答案包括一个名为rtldi的程序的链接，该程序似乎可以解决glibc问题。它是从2004年开始的，因此它可能不再直接在链接器中起作用，但是也许值得研究。它的来源是GPLv2。
我的一个朋友曾经提出过一个想法，那就是共享库的实际使用被高估了。他的确有一点：共享库最好不要用重复的文件来填充计算机的内存，但是考虑到单个应用程序实例，这只有几MB。
只有少数应用程序可以采取行动，例如为其提供自己的glibc。为我们省去冗长的分析，我们称它们为“即时应用程序”，它们在完成工作的意义上是自用的。例如，Web浏览器，邮件用户代理，办公套装和音乐播放器允许用户获得他们想要的东西，而每个用户只有几个实例。从另一方面来说，系统服务，窗口管理器甚至整个桌面环境都非常重要，而仅仅是提供支持，通常并不足够罕见或重要，因此人们愿意为他们提供自己的glibc。
“即时应用程序”的数量非常少，绝对是每个用户使用的，与近来产生的“基本” OS和DE相比，数量相对较少。如果像Chrome，Firefox这样的即时应用程序是静态编译的，则平均系统所需的额外内存将为几百MB。在当今的许多GB系统上，这一论点并没有多大用处，因此可以将静态链接用于直接应用程序作为一种选择。
还有交换空间和SSD的概念，它们可以实现快速的交换/输出，这也有助于处理增加的内存需求。
通过静态链接并不能真正解决这里讨论的glibc问题，但是对于Web浏览器之类的应用程序，可以想到一种自包含的分发格式，其中X协议，某些声音守护程序和某些内核methods是唯一的接口。优点是减少了库版本的不兼容性。
/lib，其中202MB是内核模块。是的，它/usr/lib是4GB，但是对于单个程序需要多少钱，它尚无定论。处理器的缓存只有几个MB。随着类似最新的Web浏览器之类的内存消耗，静态链接的二进制文件对缓存的影响也不会那么大，并且并发运行的程序数量不会减少。也是因为缓存相对较小。我的估计似乎比您的估计更准确。嗯是的
du -h /lib，请尝试），但请记住，如果以静态方式编译这些库，则每个库都需要一定数量的RAM。以及使用它们编译的每个应用程序。 因此，例如。您有两个使用相同库堆栈的应用程序，现在需要两倍的内存。三个应用程序？三倍。更不用说它会在很大程度上抵消缓存的好处...