不同Linux内核版本除gcc外对C文件编译的影响及m5threads报错咨询

• 内核用户态头文件（UAPI）变更：内核对外暴露的用户空间头文件（如<linux/futex.h>、<asm/unistd.h>等）会随版本迭代修改结构体定义、宏、系统调用号，若代码直接依赖这类头文件的内部细节，不同内核版本下会出现编译期定义找不到、类型不匹配的错误。
• 配套C标准库（glibc）的实现差异：glibc版本通常与发行版适配的内核版本强绑定，旧内核配套的glibc中，pthread线程库、系统调用封装的内部私有结构和高版本glibc完全不同，且这类私有结构没有兼容约定，跨版本直接访问必然出错。
• 静态链接的内核依赖约束：若编译时使用-static参数做静态链接，高版本glibc的静态库本身会依赖高版本内核的新功能特性，即使使用旧gcc编译，生成的二进制也无法在旧内核正常运行。
• 系统调用ABI变更：极少数场景下内核会调整特定系统调用的参数传递规则、返回值结构，这类问题一般表现为编译通过但运行时报错，不属于你当前遇到的编译失败场景。

你遇到的结构体成员找不到的报错，和gcc版本无关，是因为你当前系统的glibc版本过高，和m5threads依赖的旧版glibc内部pthread结构不匹配：m5threads的pthread.c直接访问了glibc pthread读写锁、条件变量的私有成员__lock、__nr_readers等，这些成员在高版本glibc中已经被删除或重命名。
对应的解决方案：

• 最简单的方案是使用容器部署旧版发行版：拉取Ubuntu 14.04这类适配Linux 3.19内核的旧镜像，自带gcc 4.8和匹配版本的glibc，直接编译不会出现兼容问题。
• 若不想使用容器，可手动下载对应版本的glibc头文件与静态库，编译时通过gcc的--sysroot参数指定旧glibc的路径，强制gcc引用旧版头文件而非系统当前的高版本glibc头文件。

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