我在运行GLIBC 2.12版本的代码时遇到这个错误，它是在2.19编译的。这个问题的标准解决方案是什么，以便代码可以在所有版本中运行。将目标机器升级到2.19不是一个选项，因为该软件应该在至少 5000 台机器上运行。Dow 将开发机器分级为 2.12 也不是一个合适的解决方案。因为 2.19 只是一个例子。 5000 台目标机器可以有任何版本。对此的标准解决方案是什么？无论如何静态编译？我的意思是将整个 GLIBC 与代码捆绑在一起。
【问题讨论】：
标签： c++ c compilation glibc
最简单的解决方案是简单地创建一个用于生产构建的“构建服务器”，并将此服务器保持在您需要支持的所有内容的最旧版本上，包括 glibc。
如果您不想使用物理机，可以使用开发服务器中的虚拟机来完成此操作。
【讨论】：
针对 glibc 编译的二进制文件应该是向前兼容的；您针对 glibc 2.19 编译的二进制文件使用的是 2.14 中出现的 API 版本。相反，如果您针对 2.12 进行编译，它应该也可以在运行时与 Glibc 2.19 一起使用。
在 Python 领域，他们现在提供基于 Centos 5.11 Docker 映像构建的预构建 Linux C 扩展； The PEP 0513 explains details。他们似乎在那里工作得很好。 Centos 5.11 好像有 glibc 2.5； Centos 6 有 glibc 2.12。我自己在 Ubuntu 14.04 和 15.10 上使用这些预构建的 .sos 没有任何问题。
【讨论】：
还有一个非常 hackish 的解决方案，将所需的 libc.so (2.19) 文件放在特定目录中（只需将其复制过来），创建一个运行脚本，在其中将 LD_LIBRARY_PATH 设置为具有特定目录然后你运行可执行文件。系统应该从系统提供的目录之前的特定目录中提取 libc.so，所以它应该可以工作。
【讨论】：