2014-10-16 14 views
12

Ich verwende GCC Linaro Compiler zum Kompilieren meines Codes. Es wirft den Fehler unknown type name size_t von libio.h. Sein eingeschlossen von stdio.h. In meinem Code schließe ich gerade stdio.h ein.GCC-Linaro-Compiler löst den Fehler "unbekannter Typ Name size_t"

Kann jemand bitte, wie man diesen Fehler auflöst.

+2

Zeigen Sie Ihren Code. Wir können nicht helfen, ohne Ihren Code zu sehen. –

+0

Wenn 'size_t not found' Fehler von meinem Code bedeutet, hätte ich '#define size_t unsigned long' zum temporären Kompilieren gemacht. Dieser Fehler stammt jedoch von dieser System-Headerdatei 'libio.h', die in diesem Compiler vorhanden ist. – rashok

+1

Sie könnten auch die vorverarbeitete Form mit 'gcc -Wall -C -E 'bekommen und mit' gcc -Wall -g -H' kompilieren, um die enthaltenen Header zu erhalten. Und 'libio.h' ist sehr wahrscheinlich kein Compiler-spezifischer Header (sondern ein' libc'-spezifischer) –

Antwort

27

Gemäß C99, §7.17, size_t ist kein eingebauter Typ, sondern definiert in <stddef.h>.

Einschließlich der <stddef.h> Header sollte Ihr Problem beheben.

2

Für was es wert ist, hatte ich genau das gleiche Problem mit einem QT-Projekt, wo ich einen Linaro-Compiler zu verwenden (auf x86 Windows und x86 Linux) für ARM Linux zu bauen. Unter Verwendung des exakt gleichen Codes und der .pro-Datei hatte ich keine Probleme, auf Windows aufzubauen, aber ich hatte eine Menge Fehler auf der Linux-Box, angefangen mit der unknown type name 'size_t' in libio.h, die zurückverfolgt zu einer #include <stdio.h>. Ich schaute in der stdio.h (in der Sysroot für die Ziel-Hardware, nicht auf dem Host-Rechner), und ein paar Zeilen nach unten war #include <stddef.h> (viel vor #include <libio.h>), so stddef.h wurde definitiv aufgenommen. Bei einer weiteren Überprüfung war stddef.h jedoch vollständig leer mit einer Dateigröße von 1 Byte. Dies galt für stddef.h in meinem Sysroot und auf meinem Host-Rechner. Ich habe keine Ahnung, warum diese Dateien leer waren.

Wie auch immer, stellte sich heraus, ich hatte eine fremde INCLUDEPATH += /usr/include/linux in meiner .pro-Datei. Auf meiner Linux-Build-Maschine fügte dies -I/usr/include/linux zu dem Makefile hinzu, das von qmake erzeugt wurde. Auf meiner Windows-Build-Maschine fügte dies -isystem /usr/include/linux zu dem Makefile hinzu, das von qmake generiert wurde. Sobald ich dies auskommentiert habe, wurden diese Zeilen aus den Makefiles entfernt und direkt auf beiden Build-Maschinen erstellt. -isystem /usr/include/linux hat anscheinend nie Probleme auf der Windows-Build-Maschine verursacht, so dass es keinen Schaden bei der Entfernung INCLUDEPATH += /usr/include/linux gab.

Ich weiß nicht wirklich, warum dies mein Problem behoben, aber ich vermute, es war eine Art von Konflikt zwischen den Header-Dateien. Vielleicht war es das Mischen von Host-Header-Dateien mit Sysroot-Header-Dateien oder das Erstellen einer zirkulären Abhängigkeit. GCC-Dokumentation besagt, dass alles, was mit der Option -I enthalten ist, Vorrang vor einer System-Header-Datei hat. Mein bester Rat für dieses Problem ist, genau zu prüfen, welche Header-Dateien enthalten sind und woher sie kommen.