CentOS编译libmemcached时config.h引发多类型声明错误的排查与求助

这个问题的核心是预处理器宏替换与系统头文件的类型定义冲突，下面一步步拆解原因和解决方案：

问题根源 #

你的config.h里的这些宏定义：

#define off_t long int
#define pid_t int
#define ssize_t int

是autoconf生成的，本意是在系统头文件未定义这些类型时提供兜底定义。但CentOS的<sys/types.h>其实已经通过typedef定义了off_t、pid_t、ssize_t这些类型。

当编译时，config.h的宏先于系统头文件生效，会把系统头文件里的代码：

typedef __off_t off_t;

替换成：

typedef __off_t long int;

这就导致编译器看到“一次声明里有多个类型”，直接抛出错误——因为typedef语法要求后面只能跟一个目标类型。

至于Ubuntu下没问题，是因为Ubuntu的gcc版本（9.3）对应的系统头文件检测逻辑更严格，autoconf在运行时会发现系统已经定义了这些类型，所以不会在config.h里生成多余的#define。

解决方案 #

1. 从根源修复：重新运行configure（推荐） #

autoconf的缓存可能导致它误判系统未定义这些类型，先清除缓存再重新配置：

# 清理之前的编译产物和配置缓存
make distclean
# 重新运行configure，让它正确检测系统类型
./configure
# 重新编译
make

这次configure会正确识别CentOS系统已经提供了这些类型的定义，不会再在config.h里生成那些冲突的#define。

2. 手动修改config.h（临时修复） #

如果重新configure无效，可以直接修改config.h，把冲突的宏定义注释或删除：

/* 注释掉这些冲突的定义，因为系统已经通过<sys/types.h>提供了正确的类型 */
/* #define off_t long int */
/* #define pid_t int */
/* #define ssize_t int */

修改后重新编译即可解决错误。

3. 代码层面规避（不推荐，仅作参考） #

如果无法修改config.h或configure脚本，可以调整头文件包含顺序：在包含config.h之前，先包含<sys/types.h>，让系统的typedef先生效，这样宏替换就不会影响系统头文件的代码。比如在libhashkit/common.h里调整顺序：

#include <sys/types.h>
#include "config.h"
// 其他头文件...

不过这种方法需要修改libmemcached的源码，不如前两种方案彻底。

验证你的测试代码现象 #

你做的测试完全符合这个逻辑：

• 测试代码1先包含<stdio.h>（间接包含了<sys/types.h>），系统已经typedef了off_t，之后的#define只会替换代码里的off_t，但代码里没用到这个类型，所以没问题；
• 测试代码2先#define off_t，再包含<stdio.h>，导致系统头文件的typedef被破坏，触发错误；
• 改成offt没问题，因为这不是系统预留的类型名称，不会和系统头文件的定义冲突。

内容的提问来源于stack exchange，提问作者Tiina