estoy usando CCG Linaro compilador para compilar mi código. Está tirando el error unknown type name size_t
de libio.h
. Está incluido desde stdio.h
. En mi código solo estoy incluyendo stdio.h
.
¿Puede alguien por favor cómo resolver este error?
Según C99, §7.17, size_t
no es un tipo incorporado sino definido en <stddef.h>
.
Incluyendo el <stddef.h>
El encabezado debería solucionar su problema.
-
También se define en
<stdio.h>
y en varios otros encabezados estándar. La pregunta no nos brinda suficiente información para determinar por qué se queja el compilador.–Keith Thompson
30 de diciembre de 2018 a las 20:55
Por lo que vale, tuve exactamente el mismo problema con un proyecto QT, donde estaba usando un compilador Linaro (tanto en Windows x86 como en Linux x86) compilar para ARM Linux. Usando exactamente el mismo código y archivo .pro, no tuve problemas para compilar en Windows, pero tuve una letanía de errores al compilar en la caja de Linux, comenzando con el unknown type name 'size_t'
en libio.h
que se remonta a un #include <stdio.h>
. miré en el stdio.h
(en el sysroot para el hardware de destino, no en la máquina host), y unas líneas más abajo estaba #include <stddef.h>
(mucho antes #include <libio.h>
), asi que stddef.h
definitivamente estaba siendo incluido. Sin embargo, tras una inspección más detallada, stddef.h
estaba completamente vacío con un tamaño de archivo de 1 byte. Esto era cierto para stddef.h
en mi sysroot y en mi máquina host. No tengo idea de por qué estos archivos estaban vacíos.
De todos modos, resulta que tenía un extraño INCLUDEPATH += /usr/include/linux
En mi perfil. En mi máquina de compilación Linux, esto agregó -I/usr/include/linux
al Makefile generado por qmake. En mi máquina de compilación de Windows, esto agregó -isystem /usr/include/linux
al Makefile generado por qmake. Una vez que comenté esto, estas líneas se eliminaron de los Makefiles y se acumularon en ambas máquinas de compilación. -isystem /usr/include/linux
aparentemente nunca causó ningún problema en la máquina de compilación de Windows, por lo que no hubo daño al eliminar INCLUDEPATH += /usr/include/linux
.
Realmente no sé por qué esto solucionó mi problema, pero sospecho que fue algún tipo de conflicto entre los archivos de encabezado. Quizás estaba mezclando archivos de encabezado de host con archivos de encabezado sysroot, o creando una dependencia circular de alguna manera. La documentación de GCC dice que cualquier cosa incluida con el -I
La opción tendrá prioridad sobre un archivo de encabezado del sistema. Mi mejor consejo para este problema es analizar detenidamente exactamente qué archivos de encabezado se incluyen y de dónde provienen.
-
Solo estaba compilando ffmpeg y, tratando de que se reconociera un determinado archivo de encabezado, agregué /usr/include/linux a los directorios de inclusión. Más tarde tuve el problema anterior y, a través de su respuesta, la eliminación de /usr/include/linux (y el uso de un directorio más adecuado para los encabezados necesarios) resolvió el problema.
– qdin
24 de abril de 2019 a las 14:19
Ambas cosas stdio.h
y stdlib.h
incluir el tipo de datos size_t
. Incluyen este tipo de datos porque las funciones declaradas en estos encabezados toman size_t
como un parámetro, o devolverlo como un tipo de devolución. size_t
en sí mismo es un typedef
a un tipo integral sin signo y también es devuelto por el sizeof
operador.
y porque el sizeof
El operador está integrado en el propio lenguaje de programación C, no incluido a través de alguna biblioteca, entonces, ¿cómo puede size_t
ser un nombre de tipo desconocido?
-
los
sizeof
El operador produce un resultado de algún tipo de entero sin signo definido por la implementación. El nombresize_t
para ese tipo se define en varios encabezados estándar y no es visible a menos que se incluya al menos uno de esos encabezados. Su respuesta intenta explicar por qué el problema sobre el que pregunta el OP no puede ocurrir, por lo que no está respondiendo la pregunta.–Keith Thompson
30/12/2018 a las 21:00
Muestra tu código. No podemos ayudarte sin ver tu código.
– Basile Starynkevitch
16/10/2014 a las 17:32
Si
size_t not found
el error es de mi código significa que lo habría hecho#define size_t unsigned long
para compilar temporalmente. Pero este error proviene de este archivo de encabezado del sistemalibio.h
que está presente dentro de este compilador.– rashok
16/10/2014 a las 17:34
También puede obtener el formulario preprocesado con
gcc -Wall -C -E
y compilar congcc -Wall -g -H
para obtener los encabezados incluidos. Ylibio.h
es muy probable que no sea un encabezado específico del compilador (sino unlibc
uno específico)– Basile Starynkevitch
16/10/2014 a las 17:35
@raja ashok Nunca usaría un #define donde se podría usar un typedef.
– usuario1171983
16/10/2014 a las 18:11
no había oído hablar
libio.h
. Existe en mi sistema, con#warning "<libio.h> is deprecated; use <stdio.h> instead."
. No lo uses.–Keith Thompson
30 de diciembre de 2018 a las 21:02