这里编译的AC程序在我们的Ubuntu服务器上运行良好。 但是当其他人试图在他们特定的Linux服务器上运行它时，会出现以下错误：
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./myprog-install) ./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.7' not found (required by ./myprog-install) 我是否需要升级我们的glibc库并重新编译？ 或者他们在服务器上丢失了什么？
如果我运行apt-cache显示libc6我的Ubuntu告诉我的版本是：
Package: libc6 Priority: required Section: libs Installed-Size: 9368 Maintainer: Ubuntu Core developers <ubuntu-devel-discuss@lists.ubuntu.com> Original-Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org> Architecture: i386 Source: eglibc Version: 2.11.1-0ubuntu7.10
如果我看http://packages.ubuntu.com/hardy/libc6目前的版本似乎是2.7-10ubuntu8.1。
我很困惑的数字。 一方面2.11-1-0是比2.7-11更高的数字。 另一方面，7.10是小于8.1的数字。
这只是我升级C库包和重新编译的问题吗？ 或者是其他人的服务器缺less一些需要的库在那里兼容？
你已经建立在glibc-2.11系统上。 您试图在glibc-2.3或更旧版本的系统上运行。 这是行不通的。
这只是我升级C库包的一个问题
否：升级你的glibc只会让事情变得更糟 。
您可能想尝试这里列出的解决方案。
这是我们可以合理地要求对方升级他们的系统来支持，而不是降级我们的编译器吗？
通常，客户端会强烈抵制升级他们系统的请求：对他们来说工作正常，任何升级都可能破坏其他现有的应用程序。
如果您打算在Linux上分发二进制文件（而不是在目标系统上构建二进制文件），那么您需要学习如何制作可在任何地方运行的二进制代码，或者您需要声明您的要求（最低内核和libc版本等），并将不能满足这些要求的客户转移。
更新：
他们为什么得到两个错误。 为什么他们没有得到一个GLIBC_2.11.1，这显然是我建立的？
符号版本控制不能这样工作。
当一个新的符号被引入时，它被标记为当前的 libc版本，例如readdir64@@GLIBC_2.2 ， posix_spawn@@GLIBC_2.15等
当你连接一个使用上述两个符号的程序，并尝试在例如glibc-2.1系统上运行它，你会得到两个错误。
但是，如果你链接的程序不使用任何上述符号，例如
int main() { return 0; }
那么你的程序将运行没有任何错误。
更新2：
他们不必将GLIBC_2.4和GLIBC2.7都添加到他们的Linux系统中，是吗？
不，他们不。 GLIBC_2.11将包含所有以前的符号。 实际上，即使他们想要安装glibc-2.4和2.7，也不能同时安装多个版本，也不可能在默认位置安装多个版本。
你已经建立了一个新的glibc版本。 建立一个老版本的glibc，最好是他们正在使用的那个。