Druckbare Version
Ich versuche gerade ob ich gcc 4.1.2 unter Amiga OS compiliert bekomme.
Weil ich den etwas angestaubten 2.95 gerne ersetzen würde.
Das ganze bricht bei "libiberty/hex.c" ab:
In stdio.h ist EOF so definiert:Zitat:
"hex.c requires EOF == -1"
Was ist der Unterschied zwischen "-1" und "(-1)"?Zitat:
#define EOF (-1)
Kann ich einfach fürs compilieren EOF auf "-1" setzen? Also ohne Klammern herum.
Oder entstehen dann irgendwelche Fehler?
theoretisch gibt es keinen unterschied... die klammern rum sind eigentlich auch gut, somit sollte der compiler besser damit umgehen können.
ist in der hex.c die stdio.h included?
greetz
Ja ist in "hex.c" eingebunden:
Zitat:
#include <stdio.h> /* for EOF */
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "libiberty.h"
#include "safe-ctype.h" /* for HOST_CHARSET_ASCII */
#if EOF != -1
#error "hex.c requires EOF == -1"
#endif
Und damit hast du dir praktisch deine Frage selbst beantwortet.
Code:#if EOF != -1
#error "hex.c requires EOF == -1"
#endif
Haben die Klammern bei "(-1)" in stdio.h wirklich einen Sinn oder kann ich EOF einfach
auf "-1" setzen? Das ist es was ich wissen möchte.
Ja kann es denn wirklich nötig sein, den Quellcode des gcc von Hand editieren zu müssen um ihn übersetzen zu können?
Das kann ja wohl kaum im Sinne der Entwickler sein!?
@Boron: Das ist dann noetig, wenn man gcc mit einer alten Version uebersetzen will, die eben nicht #define EOF (-1) versteht.
Er schreibt ja, dass er gcc 2.95 verwendet, und die ist wirklich nicht neu.
Leider kann ich das jetzt nicht testen, ich benutze schon den 4.1.2er.
Ja es liegt am gcc 2.95.3. Der versteht nicht einmal -1, also ohne Klammern.
Scheint ein Bug im Preprozessor bei #if zu sein.
Ich nehme jetzt halt den 3.3er, der als "unstable" eingestuft wird.
Der läuft gerade.