当我编译一个简单的Hello World！在我的本地 Debian lenny x64 上使用 sscanf 函数的程序，它可以工作。但是当我将相同的程序上传到运行 CentOS x86 的服务器上时，它就不起作用了。如果我不使用 sscanf，那么该程序可以在两台计算机上运行。
gcc -std=c99 -O2 -pipe -m32
如果我用 sscanf 编译它但没有 -std=c99，那么它可以在两台计算机上运行。
gcc -O2 -pipe -m32
CentOS x86 上的 sscanf 和 c99 有什么问题？我认为使用 -m32 标志编译可以在所有 Linux 上工作？ （我对 CentOS 服务器的访问权限有限，因此我无权访问错误消息。）
【问题讨论】：
sscanf() 函数在代码周围显示几行代码，并稍微描述一下“它不起作用”的确切含义。
可能 CentOS 机器使用的是旧版本的 glibc。由于他们的 scanf 实现的非标准 GNU 扩展最终导致 glibc 与 c99 冲突，他们添加了一个讨厌的 hack，在使用 -std=c99 时将 *scanf 重定向到 __isoc99_*scanf；如果您的 glibc 副本缺少 __isoc99_sscanf 符号，则程序将无法运行。
静态链接，或链接到不同的 libc 没有丑陋的向后兼容性黑客，将解决问题。
【讨论】：
您是上传二进制文件还是源代码然后重新编译？如果您正在上传二进制文件，您可能会遇到 Debian 和 CentOS 之间的库兼容性问题。
如果是这种情况，请仅上传源代码并在 CentOS 上重新编译。
【讨论】：
如果您没有编译@CentOS 的权限，请尝试编译静态二进制文件。您可以使用生成比 glibc 更小的二进制文件的dietlibc，或者尝试使用 EGLIBC，这是 Debian 将使用的默认 C 库启动 Debian “squeeze”。
【讨论】：
我遇到了类似的问题，它可以在@Ubuntu 64-bit，但是编译失败@CenseOS 64-bit (REHL5 desktop)：
错误信息是：
undefined reference to `__isoc99_sscanf@GLIBC_2.7'
当我将编译的可执行文件@Ubuntu 复制到 REHL5 并运行它时，出现了另一个错误：
elf file os abi invalid
它是在没有标志 -std=c99 的情况下编译的，我是 C 的新手，并且正在寻找一些解决方法，例如。添加一些标志。
生成文件：
CC=gcc
CCFLAGS= -Wall -O2 -DLINUX -I../include
demos:linuxdemo.c
$(CC) $(CCFLAGS) -o demoA linuxdemo.c -L../lib -lsense4 -lusb
$(CC) $(CCFLAGS) -o demoSO linuxdemo.c -lusb -lsense4
clean:
rm -f demoA
rm -f demoSO
【讨论】：
您需要将 glibc 更新到 2.7
从这里下载 rpm 包： http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/8/Everything/x86_64/os/Packages/
需求：
libc-common-2.7-2.x86_64.rpm
glibc-headers-2.7-2.x86_64.rpm
glibc-devel-2.7-2.x86_64.rpm
glibc-2.7-2.x86_64.rpm
命令：
rpm -Uvh --aid --nodeps glibc-common-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.7-2.x86_64.rpm
【讨论】：