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