gcc 4.1.2 compilieren

[jay-t]

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:



"hex.c requires EOF == -1"


In stdio.h ist EOF so definiert:



#define EOF (-1)


Was ist der Unterschied zwischen "-1" und "(-1)"?
Kann ich einfach fürs compilieren EOF auf "-1" setzen? Also ohne Klammern herum.
Oder entstehen dann irgendwelche Fehler?

[quinte17]

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

[jay-t]

Ja ist in "hex.c" eingebunden:



#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

[nul]

Und damit hast du dir praktisch deine Frage selbst beantwortet.


#if EOF != -1
#error "hex.c requires EOF == -1"
#endif

[jay-t]

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.

[Boron]

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!?

[nul]

@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.

[jay-t]

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.