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