我正在使用GCC Linaro编译器来编译我的代码。它从unknown type name size_t抛出错误libio.h。它包含在stdio.h中。在我的代码中，我只是包含stdio.h。
请问任何人如何解决此错误。
答案 0 :(得分：38)
根据C99，§7.17，size_t不是内置类型，而是在<stddef.h>中定义。
包含<stddef.h>标题可以解决您的问题。
答案 1 :(得分：5)
对于它的价值，我在QT项目中遇到了同样的问题，我使用Linaro编译器（在x86 Windows和x86 Linux上）为ARM Linux构建。使用完全相同的代码和.pro文件，我在Windows上构建时没有任何问题，但我在Linux机器上构建了一连串的错误，从unknown type name 'size_t'中的libio.h开始追溯到#include <stdio.h>。我查看了stdio.h（在sysroot中用于目标硬件，而不是在主机上），并且向下几行是#include <stddef.h>（比#include <libio.h>之前多得多），所以{{1肯定被包括在内。但是，经过进一步检查，stddef.h完全为空，文件大小为1个字节。对于我的sysroot和我的主机上的stddef.h，情况都是如此。我不知道为什么这些文件是空的。
无论如何，事实证明我的.pro文件中有一个无关的stddef.h。在我的Linux构建机器上，这将INCLUDEPATH += /usr/include/linux添加到qmake生成的Makefile中。在我的Windows构建计算机上，这将-I/usr/include/linux添加到qmake生成的Makefile中。一旦我对此进行了评论，就会从Makefile中删除这些行，并在两台构建机器上构建它们。 -isystem /usr/include/linux显然从未在Windows构建计算机上造成任何问题，因此删除-isystem /usr/include/linux没有任何害处。
我真的不知道为什么这解决了我的问题，但我怀疑这是头文件之间的某种冲突。也许它是将主机头文件与sysroot头文件混合，或以某种方式创建循环依赖。 GCC文档说明INCLUDEPATH += /usr/include/linux选项中包含的任何内容都优先于系统头文件。我对这个问题的最好建议是仔细查看包含哪些头文件以及它们来自哪里。
答案 2 :(得分：0)
stdio.h和stdlib.h都包含数据类型size_t。它们包含此数据类型，因为在这些标头中声明的函数将size_t作为参数，或将其作为返回类型返回。 size_t本身是无符号整数类型的typedef，它也由sizeof运算符返回。
并且由于sizeof运算符是C编程语言本身内置的，而不是通过某些库提供的，那么size_t怎么能成为未知类型名称？