GCC Build-Problem (#include_next limits.h)

Wenn ich versucheGCC Build-Problem (#include_next limits.h)

$ make depend -f gcc.mak

eine Middleware auf meinem Ubuntu-Rechner bekomme ich diesen

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

Dies ist der Inhalt um 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

ich habe versucht Einstellung

 
$ 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/

(wo ich eine andere limits.h auf meinem System gefunden habe). Ich habe bereits libc6-dev installiert, könnte es sein, dass limits.h von einem anderen Paket überschrieben wurde? Brauche ich ein anderes -dev-Paket? Oder ist eine Umgebungsvariable erforderlich? vielleicht könnte das auf andere Weise umgangen werden?

Quelle

2009-05-16 Jonas Byström

Dies sollte so funktionieren wie es ist. Was siehst du, wenn du '-v' zu deinem Kompilierbefehl hinzufügst? –

Ich vermute, dass limits.h fehlt (oder überschrieben). -v bekommt mich GNU Make 3.81 Ziel: x86_64-linux-gnu gcc-version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) –

Die andere limits.h, die Sie finden können, ist derjenige, der von Include_next gezogen werden sollte . Können Sie der Befehlszeile von gcc, die die fehlerhafte Kompilierung ausführt, -v hinzufügen, d. H. Gcc -v -c foo.c? Der interessante Teil hier in seiner Ausgabe beginnt # include <...> Suche wäre: /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-fixed /usr/include Ende der Suchliste. –

das Paket, das Sie benötigen, ist glibc.

Quelle

2009-12-26 21:39:18

Das klingt richtig. Ich werde es als Lösung bezeichnen, auch wenn ich es nicht überprüft habe. –

Ich habe Glibc und bekomme immer noch diesen Fehler. – Reinderien

Ich versuche für Android zu kompilieren (also keine Glibc als solche) und ich bekomme diesen Fehler auch. Kann nicht herausfinden, welchen Header ich einschließen sollte. – Wyatt8740

Verwenden Sie #include_next <limits.h> (gcc-Erweiterung), um zu erzwingen, dass gcc den nächsten gefundenen limits.h im Include-Pfad anzeigt (was die Kopie des Toolsets sein sollte).

Quelle

2009-05-16 08:13:25 ASk

Ich habe keine anderen (sinnvollen) Grenzen.h. Ich brauche die GCC limits.h. Der in include-fixed scheint ... aus. –

Ich erinnere mich nicht genau die Auflösung nicht mehr, aber es hatte mit einigen fehlenden Paketen zu tun. Nachdem ich etwas mehr bekommen hatte, funktionierte es für mich.

Quelle

2009-08-10 09:35:01

Ich hatte mein Problem mit dem Kompilieren mit STLport 5.1.5, konfrontiert aber sieht aus wie das Problem behoben ist STLport 5.2.0 ist. Das Problem ist in STLport Release Notes dokumentiert. Nachdem eine Kopie von STLport 5.2.1 erstellt wurde, ging die Kompilierung erfolgreich ohne Schluckauf.

Quelle

2011-06-16 05:21:42 sudar

Ich habe dieses Problem gestoßen eine Quer Kompilierung zu tun. Wenn Sie ausführen ein ‚abhängig machen‘ das Makefile das makedepend Programm wie aus dieser Zuordnung gesehen aufrufen:

MAKEDEPPROG=makedepend

makedepend nur einige Standard-Recherchen gehören das Starten Verzeichnisse mit /usr/include

Da die #include_next Richtlinie bedeutet, die einschließen Als nächstes fand die Instanz der benannten Include-Datei im Suchpfad, dies schlägt fehl, wenn keine andere gefunden wird.

Für mich war die Lösung makedepend zu lenken zuerst meine Cross-Compiler enthalten Verzeichnisse zu suchen. Ich tat dies, indem Sie die MAKEDEPPROG Zuordnung Änderung der -I Richtlinie aufzunehmen:

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

ich über das makedepend Programm empfehlen Lesen (über die ich vor nichts wusste). Zum Beispiel war es für mich nicht offensichtlich, dass makedepend keinen Umgebungssuchpfad verwendet. Die Direktive -I setzt den angegebenen Suchpfad vor die Standardpfade von makedepend.

Quelle

2016-02-22 19:32:39 JSAnderson

GCC Build-Problem (#include_next limits.h)

Antwort

Verwandte Themen