解决util-linux项目在x86_64主机上构建32位库时的编译错误

在构建util-linux项目的32位版本时，开发者可能会遇到一些特定的编译错误。这些错误主要出现在交叉编译环境下，特别是在x86_64架构的主机上构建32位库时。

问题现象

当尝试在x86_64主机上构建32位的util-linux库时，编译过程会在处理enosys.c文件时失败。错误信息显示多个系统调用号（如__NR_accept、__NR_epoll_ctl_old等）未被声明。这些错误表明系统无法正确识别32位架构下的系统调用号定义。

根本原因

经过分析，问题的根源在于生成syscalls.h头文件的过程中，构建系统没有正确传递32位架构相关的编译标志。具体来说：

1. syscalls.h是通过tools/all_syscalls工具生成的，该工具需要知道目标架构的系统调用号
2. 当前的构建配置中，生成这个头文件时没有包含CFLAGS或c_args中的架构相关参数
3. 导致工具使用默认的64位架构设置来查找系统调用号，而不是预期的32位架构

解决方案

修复方案是在生成syscalls.h时正确传递编译参数。具体修改是在meson.build文件中，将c_args选项传递给all_syscalls工具：

syscalls_h = custom_target('syscalls.h',
  input : 'tools/all_syscalls',
  output : 'syscalls.h',
  command : ['tools/all_syscalls', cc.cmd_array(), get_option('c_args')],
)

这个修改确保了生成系统调用头文件时使用了正确的架构参数，特别是关键的-m32标志。

技术背景

在Linux系统编程中，系统调用号是内核提供的服务接口标识。不同架构（如x86和x86_64）可能有不同的系统调用号定义。当进行交叉编译时，必须确保：

1. 头文件生成工具使用目标架构的配置
2. 系统调用号查询基于正确的架构定义
3. 所有编译阶段保持一致的架构设置

验证与影响

该修复已经过验证，能够成功解决32位库的构建问题。它不会影响64位构建或其他架构的编译过程，因为c_args会根据构建配置自动包含适当的架构标志。

对于项目维护者和打包人员来说，这个修复确保了util-linux项目能够在各种交叉编译场景下正常工作，特别是在需要同时提供32位和64位库的系统环境中。