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.
Zeigen Sie Ihren Code. Wir können nicht helfen, ohne Ihren Code zu sehen. –
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
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) –