2009-05-16 14 views
9

Kiedy próbujęGCC build problemem (#include_next limits.h)

$ make depend -f gcc.mak

middleware na moim komputerze Ubuntu mam ten

/usr/include/../include/limits.h:125:26: error: no include path in which to search for limits.h

To jest zawartość około limits.h: 125 :

 
/* Get the compiler's limits.h, which defines almost all the ISO constants. 

    We put this #include_next outside the double inclusion check because 
    it should be possible to include this file more than once and still get 
    the definitions from gcc's header. */ 
#if defined __GNUC__ && !defined _GCC_LIMITS_H_ 
/* `_GCC_LIMITS_H_' is what GCC's file defines. */ 
# include_next <limits.h> 
#endif 

Próbowałem ustawienie

 
$ export INCLUDE=/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed/ 
$ export C_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed/ 
$ export CPLUS_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3/include-fixed/ 

(gdzie znalazłem kolejny limit.h w moim systemie). Mam już zainstalowany libc6-dev, czy to możliwe, że jego limit.h został nadpisany przez inny pakiet? Czy potrzebuję innego pakietu -dev? Lub jest wymagana zmienna środowiskowa; może to można obejść w jakiś inny sposób?

+0

To powinno działać tak, jak jest. Co widzisz po dodaniu "-v" do polecenia kompilacji? –

+0

Zgaduję, że limit.h brakuje (lub jest nadpisany). -v dostaje mnie GNU Make 3.81 Target: x86_64-linux-gnu gcc wersja 4.3.3 (Ubuntu 4.3.3-5ubuntu4) –

+0

Kolejna granica.h, którą możesz znaleźć, to ta, która powinna zostać wciągnięta przez include_next . Czy można dodać opcję -v do wiersza polecenia gcc, który wykonuje kompilację, która nie działa, tj. Gcc -v -c foo.c? Co ciekawe w jego wyjściu będzie #include <...> wyszukiwania zaczyna się tutaj: /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include-fix /usr/include Koniec listy wyszukiwania. –

Odpowiedz

1

pakiet, którego potrzebujesz to glibc.

+0

To brzmi dobrze. Oznaczę to jako rozwiązanie, nawet jeśli go nie zweryfikowałem. –

+0

Mam glibc i nadal otrzymuję ten błąd. – Reinderien

+1

Próbuję skompilować dla Androida (więc nie glibc jako takie) i otrzymuję ten błąd też. Nie mogę znaleźć nagłówka, który powinienem dołączyć. – Wyatt8740

0

Rozważ skorzystanie z #include_next <limits.h> (rozszerzenie gcc), aby zmusić gcc do obejrzenia następnego znalezionego limits.h w ścieżce dołączania (która powinna być kopią zestawu narzędzi).

+0

Nie mam żadnych innych (sensownych) ograniczeń.h. Potrzebuję limitów GCC.h. Ten z dołączonym-naprawiony wydaje się ... wyłączony. –

0

Nie pamiętam już dokładnie rozdzielczości, ale miało to związek z brakującą paczką. Po uzyskaniu dodatkowych informacji zadziałało to dla mnie.

2

Napotkałem mój problem ze skompilowaniem ze STLport 5.1.5, ale wygląda na to, że problem został naprawiony to STLport 5.2.0. Problem jest udokumentowany w STLport Release Notes. Po uzyskaniu kopii STLport 5.2.1, kompilacja przebiegła pomyślnie bez czknięć.

2

Napotkano ten problem podczas wykonywania kompilacji krzyżowej. Kiedy wykonać „make zależeć” Makefile wywoła program makedepend jak widać z tego zadania:

MAKEDEPPROG=makedepend 

makedepend przeszukuje tylko niektóre domyślne zawierają katalogi zaczynające się /usr/include

Ponieważ dyrektywa #include_next znaczy obejmować następna znaleziona instancja podanego pliku include w ścieżce wyszukiwania, to się nie powiedzie, jeśli nie zostanie znaleziony inny.

Dla mnie rozwiązaniem było skierowanie makedepend do przeszukiwania mojego kompilatora krzyżowego, w tym katalogów. Zrobiłem to przez zmianę przyporządkowania MAKEDEPPROG zawierać dyrektywę -I:

MAKEDEPPROG=makedepend -I < path/to/cross-compiler/include-fixed > 

sugeruję czytanie o programie makedepend (o którym nic nie wiedział wcześniej). Na przykład nie było dla mnie oczywiste, że makedepend nie użyłby ścieżki wyszukiwania środowiska. Dyrektywa -I umieszcza określoną ścieżkę przeszukiwania przed domyślnymi ścieżkami makpedepend.