EDIT2:
Also hier ist ein Beispiel für das Programm:
%Vor%1) klingeln:
clang++ -std=c++0x -stdlib=libc++ -lc++ main.cc -o main
kompiliert gut.
2) g++-mp-4.8 -std=c++11 main.cc -o main gibt:
3) g++-mp-4.8 main.cc -o main kompiliert!
irgendwelche Ideen, was ist falsch mit dem Setup?
==========
Kann jemand helfen zu verstehen, was sich in Gcc / macports / os 10.9 geändert hat?
Ich hatte ein Kompilierungsskript einer Drittanbieter-Bibliothek, die in OS 10.8 arbeitet. Vor kurzem habe ich auf den neuen OSX (10.9) aktualisiert und gcc 4.7 von Macports gestoppt Verknüpfung. Insbesondere habe ich:
%Vor% Dieses Problem ist dem hier sehr ähnlich %Code%.
Es scheint jedoch, dass istype nicht in libgcc ++ .dylib sitzt.
Irgendwelche Ideen was zu versuchen?
EDIT1:
in der Tat, 4,8 behoben das Problem mit isspace , aber eine andere Oberfläche - isspace :
Was ist hier los? Hat es mit dem neuen Xcode (5.0) zu tun?
Die meisten ctype.h -Elemente sind als Inline-Definitionen deklariert, sodass sie zum Zeitpunkt der Kompilierung erweitert werden. Wenn Sie ohne -std=c++11 kompilieren, wird es erweitert zu:
Wenn Sie mit -std=c++11 kompilieren, wird es zu:
Aus irgendeinem Grund ignoriert g ++ dann die perfekte Definition, die dort präsentiert wird.
Basierend auf dem Kommentar zu diesem ungültigen Fehler , wählt gcc, den Code nicht zu optimieren und nach der Definition in einer der verbundenen Bibliotheken suchen.
Ein Workaround scheint zu sein, mit mindestens -O1 -Optimierung zu kompilieren, was das Problem vermeidet, aber es ist ein echter Schmerz in den Arsch.
Wenn wir nun die Unterschiede in den # Definitionen zwischen Nicht-C ++ 11 und C ++ 11 betrachten, sehen wir, dass wir ein extra #define haben:
%Vor% und wegen eines Stücks Code im 10.9 SDK ( usr/include/sys/cdefs.h ) werden all diese __DARWIN_CTYPE_TOP_inline in cytpe.h in __header_inline umgewandelt, die dank dieses kleinen zusätzlichen Codes in extern __inline __attribute__((__gnu_inline__)) umgewandelt werden :
Es sieht so aus, als ob Apples Header versucht, das Richtige zu tun, aber sie haben nicht alle ihre Basen abgedeckt. Es gibt ein anderes Problem , das einen ähnlichen Fehler erwähnt.
Ich lese seit einigen Tagen Linke-Fehler mit dem Außenseiter. Das Problem scheint mit bestimmten Tools zu bestehen, die früher kompatibel waren, aber länger sind.
Haben Sie versucht, alle Tools zu zwingen, einen Typ clang ++ oder llvm-g ++ zu verwenden?