El compilador GCC linaro arroja el error “nombre de tipo desconocido size_t”

5 minutos de lectura

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?

  • 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 sistema libio.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 con gcc -Wall -g -H para obtener los encabezados incluidos. Y libio.h es muy probable que no sea un encabezado específico del compilador (sino un libc 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

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 nombre size_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

¿Ha sido útil esta solución?