I am using GCC Linaro compiler for compiling my code. Its throwing the error unknown type name size_t from libio.h. Its included from stdio.h. In my code I am just including stdio.h.
Can any one please how to resolve this error.
3 Answers
As per C99, §7.17, size_t is not a builtin type but defined in <stddef.h>.
Including the <stddef.h> header should fix your problem.
-
2It's also defined in
<stdio.h>, and in several other standard headers. The question doesn't give us enough information to determine why the compiler is complaining. Commented Dec 30, 2018 at 20:55
For what it's worth, I had this exact same problem with a QT project, where I was using a Linaro compiler to (on both x86 Windows and x86 Linux) build for ARM Linux. Using the exact same code and .pro file, I had no problems building on Windows, but I had a litany of errors building on the Linux box, beginning with the unknown type name 'size_t' in libio.h which traced back to a #include <stdio.h>. I looked in the stdio.h (in the sysroot for the target hardware, not on the host machine), and a few lines down was #include <stddef.h> (much before #include <libio.h>), so stddef.h was definitely getting included. However, upon further inspection, stddef.h was completely empty with a file size of 1 byte. This was true for stddef.h in my sysroot and on my host machine. I have no idea why these files were empty.
Anyway, turns out I had an extraneous INCLUDEPATH += /usr/include/linux in my .pro file. On my Linux build machine, this added -I/usr/include/linux to the Makefile generated by qmake. On my Windows build machine, this added -isystem /usr/include/linux to the Makefile generated by qmake. Once I commented this out, these lines were removed from the Makefiles and it built right up on both build machines. -isystem /usr/include/linux apparently never caused any trouble on the Windows build machine, so there was no harm in removing INCLUDEPATH += /usr/include/linux.
I don't really know why this fixed my problem, but I suspect it was some kind of conflict between header files. Perhaps it was mixing host header files with sysroot header files, or creating a circular dependency somehow. GCC documentation says that anything included with the -I option will take precedence over a system header file. My best advice for this problem is to take a hard look at exactly which header files are being included and where they are coming from.
-
1I was just building ffmpeg, and, trying to get a certain header file to be recognized, I added /usr/include/linux to the include dirs. Later on I had the above problem, and via your answer, removing /usr/include/linux (and using a more proper directory for the needed headers) solved the problem.– qdinCommented Apr 24, 2019 at 14:19
Both stdio.h and stdlib.h include the data type size_t. They include this data type because the functions declared in these headers either take size_t as a parameter, or return it as a return type. size_t itself is a typedef to an unsigned integral type and it's also returned by the sizeof operator.
And because the sizeof operator is built into the C Programming Language itself, not included via some library, then how can size_t be an unknown type name?
-
1The
sizeofoperator yields a result of some implementation-defined unsigned integer type. The namesize_tfor that type is defined in several standard headers, and is not visible unless at least one of those headers is included. Your answer tries to explain why the problem the OP is asking about can't occur, so you're not answering the question. Commented Dec 30, 2018 at 21:00
size_t not founderror is from my code means, I would have done#define size_t unsigned longfor compiling temporarily. But this error is from this system header filelibio.hwhich is present inside this compiler.gcc -Wall -C -Eand compile withgcc -Wall -g -Hto get the included headers. Andlibio.his very probably not a compiler-specific header (but alibcspecific one)libio.h. It exists on my system, with#warning "<libio.h> is deprecated; use <stdio.h> instead.". Don't use it.