2014-10-16 15 views
12

Używam kompilatora GCC Linaro do kompilowania mojego kodu. Rzucanie błędu unknown type name size_t z libio.h. Jest zawarty w stdio.h. W moim kodzie po prostu włączam stdio.h.GCC kompilator linaro zgłasza błąd "nieznana nazwa nazwa size_t"

Czy ktoś może rozwiązać ten błąd.

+2

Pokaż swój kod. Nie możemy pomóc bez zobaczenia Twojego kodu. –

+0

Jeśli błąd 'size_t nie znaleziony' jest z mojego kodu oznacza, zrobiłbym' #define size_t unsigned long' do kompilacji tymczasowo. Ale ten błąd pochodzi z tego pliku nagłówkowego systemu 'libio.h', który jest obecny wewnątrz tego kompilatora. – rashok

+1

Możesz również uzyskać wstępnie przetworzony formularz za pomocą 'gcc-Wall-C-E 'i skompilować z' gcc-Wall-g -H', aby uzyskać dołączone nagłówki. A 'libio.h' prawdopodobnie nie jest nagłówkiem specyficznym dla kompilatora (ale specyficznym dla' libc') –

Odpowiedz

27

Zgodnie z C99, §7.17, size_t nie jest typem wbudowanym, ale zdefiniowanym w <stddef.h>.

Włączenie nagłówka <stddef.h> powinno rozwiązać problem.

2

Co jest warte, miałem dokładnie ten sam problem z projektem QT, w którym używałem kompilatora Linaro do (na X86 Windows i x86 Linux) dla ARM Linux. Używając dokładnie tego samego kodu i pliku .pro, nie miałem problemów z budowaniem w systemie Windows, ale miałem mnóstwo błędów budujących się na Linuksie, zaczynając od unknown type name 'size_t' w libio.h, co miało związek z #include <stdio.h>. Spojrzałem na stdio.h (w sysroot dla docelowego sprzętu, a nie na maszynie hosta), a kilka linii w dół było #include <stddef.h> (dużo przed #include <libio.h>), więc z pewnością zostałem dołączony do stddef.h. Jednak po dalszej inspekcji numer stddef.h był całkowicie pusty, a rozmiar pliku to 1 bajt. Było to prawdą dla stddef.h w moim sysroot i na komputerze hosta. Nie mam pojęcia, dlaczego te pliki były puste.

W każdym razie okazało się, że w moim pliku .pro mam obcego INCLUDEPATH += /usr/include/linux. Na mojej maszynie do kompilacji Linuksa dodałem -I/usr/include/linux do pliku Makefile wygenerowanego przez qmake. Na moim komputerze do budowy systemu Windows ten plik dodano do pliku Makefile wygenerowanego przez qmake. Kiedy to skomentowałem, linie zostały usunięte z plików Makefile i zostały zbudowane na obu maszynach budujących. -isystem /usr/include/linux podobno nigdy nie powodowało żadnych problemów na maszynie do budowy systemu Windows, więc nie było żadnej szkody przy usuwaniu INCLUDEPATH += /usr/include/linux.

Naprawdę nie wiem, dlaczego to naprawiło mój problem, ale podejrzewam, że był to jakiś konflikt między plikami nagłówkowymi. Być może było to mieszanie plików nagłówkowych hosta z plikami nagłówkowymi sysroot lub tworzenie zależności cyklicznej. Dokumentacja GCC mówi, że wszystko zawarte w opcji -I ma pierwszeństwo przed plikiem nagłówkowym systemu. Moja najlepsza rada dotycząca tego problemu polega na dokładnym przyjrzeniu się, które pliki nagłówkowe są dołączane i skąd pochodzą.

Powiązane problemy