GCC 3.3 - amiga-news.de Forum

amiga-news.de Forum > Programmierung > GCC 3.3

[ - Search - New posts - Register - Login - ]

-1-

[ - Post reply - ]

2003-08-27, 16:21 h

gni
Posts: 1106
User

Benutzt (ausser mir :-) jemand GCC 3.3 unter AmigaOS/m68k? Gibt es Schwierigkeiten bei der Installation und/oder bei der Nutzung?

[ - Answer - Quote - Direct link - ]

2003-08-28, 14:28 h

Solar
Posts: 3680
User

Zitat:
Original von gni:
Benutzt (ausser mir :-) jemand GCC 3.3...

Ja!

Zitat:
...unter AmigaOS/m68k?

Öh... nein.

Würde mich aber auch interessieren, ob das geht...

[ - Answer - Quote - Direct link - ]

2003-08-28, 16:14 h

gni
Posts: 1106
User

Zitat:
Original von Solar:

Zitat:
...unter AmigaOS/m68k?
Öh... nein. Würde mich aber auch interessieren, ob das geht...

Bei mir gehts. Bei anderen nicht :-/

[ - Answer - Quote - Direct link - ]

2003-08-28, 18:31 h

_PAB_
Posts: 3016
User

Könnte doch an unterschiedlichen ixemul-Versionen liegen ?
Oder ist das ein Port ohne ixemul-Verwendung ?
Wenn ja, wäre ich auch interessiert.

[ - Answer - Quote - Direct link - ]

2003-08-29, 08:50 h

Solar
Posts: 3680
User

Zitat:
Original von gni:
Bei mir gehts. Bei anderen nicht :-/

Kannst Du den "Erfolg" reproduzieren (also von einer "leeren" AmigaOS-Installation ausgehend)? Wenn ja, dann poste doch mal eine Schritt-für-Schritt-Anleitung, und das Problem ist gelöst...

[ - Answer - Quote - Direct link - ]

2003-08-29, 11:23 h

gni
Posts: 1106
User

Zitat:
PAB:
Könnte doch an unterschiedlichen ixemul-Versionen liegen?

Das ist unwahrscheinlich. Es wird eh die "neueste" 48.2 benötigt. Daran sollte es nicht liegen.

Zitat:
Oder ist das ein Port ohne ixemul-Verwendung? Wenn ja, wäre ich auch interessiert.

Wieso nur dann? Man braucht halt *echte* UN*X-Funktionalität, die man ohne ixemul nicht hat. Bei mir läuft GCC absolut zuverlässig.

[ Dieser Beitrag wurde von gni am 29.08.2003 editiert. ]

[ - Answer - Quote - Direct link - ]

2003-08-29, 11:35 h

gni
Posts: 1106
User

Zitat:
Solar:

Zitat:
gni:
Bei mir gehts. Bei anderen nicht :-/
Kannst Du den "Erfolg" reproduzieren (also von einer "leeren" AmigaOS-Installation ausgehend)?

Wenn man eine funktionierde GG-Umgebung hat, dh. die installierte GCC Version klaglos funktioniert, dann muß auch GCC 3.3 funktionieren.

Zitat:
Wenn ja, dann poste doch mal eine Schritt-für-Schritt-Anleitung, und das Problem ist gelöst...

Man entpackt das neue bin Archiv in ein Tempverzeichnis und schiebt dann all relvanten Teile in die GG-Umgebung. Die meisten Teile können ohne Konflikte installiert werden. Wichtig ist nur das Frontend im bin Verzeichnis. Das sollte man vorher zb. in gcc3 umbenennen und das so nach bin: installieren. Dann hat man seinen alten Compiler als gcc und den neuen als gcc3. Fertig.

[ - Answer - Quote - Direct link - ]

2004-03-30, 20:32 h

Mazze
Posts: 263
User

Hi,

ich nutze mal diesen alten Beitrag zu einem Bugreport :-)
Der Linker meldet "can't find reference to putchar". Dies tritt nur auf bei -noixemul und -O1 oder größer.
Als Übeltäter erwies sich die Zeile "printf("n");". Ich weis, das dies Quatsch ist, es Stand aber so in einem Open Source Projekt.

[ - Answer - Quote - Direct link - ]

2004-04-01, 10:56 h

gni
Posts: 1106
User

Zitat:
Mazze:
ich nutze mal diesen alten Beitrag zu einem Bugreport :-)

Ich höre lieber positive Dinge ;-)

Zitat:
Der Linker meldet "can't find reference to putchar". Dies tritt nur auf bei -noixemul und -O1 oder größer.

Ist mir bekannt :-/ Ich würde das einen GCC Bug nennen. putchar ist keine ANSI/ISO Funktion und deswegen nicht Teil von libnix. stdio.h enthält putchar aber als Makro... Mittlerweile hat libnix eine putchar Funktion.

Zitat:
Als Übeltäter erwies sich die Zeile "printf("n");". Ich weis, das dies Quatsch ist, es Stand aber so in einem Open Source Projekt.

Ist leider kein Quatsch. Seit irgendeiner 3.x Version enthält der GCC stdio-Optimierungen. Dabei werden bestimmte Funktionen zb. printf durch andere ersetzt, die schneller sein sollen. Das kann man unterbinden, zb. mit -fno-builtin (the big gun) oder selektiv mit -fno-builtin-<funktion>. In diesem Fall also -fno-builtin-printf.

[ - Answer - Quote - Direct link - ]

2004-04-01, 18:22 h

Mazze
Posts: 263
User

Zitat:
Ich höre lieber positive Dinge ;-)

Es ist super, einen aktuellen GCC auf dem Amiga zu haben.

Zitat:
Ist mir bekannt :-/ Ich würde das einen GCC Bug nennen. putchar ist keine ANSI/ISO Funktion und deswegen nicht Teil von libnix. stdio.h enthält putchar aber als Makro... Mittlerweile hat libnix eine putchar Funktion.

Aha. Ich habe libpng durch Datatypes ersetzt, weil die zlib bei -noixemul Linkerfehler verursacht. Ist die aktuelle Version von libnix auf Geekgadgets?

Zitat:
Ist leider kein Quatsch. Seit irgendeiner 3.x Version enthält der GCC stdio-Optimierungen. Dabei werden bestimmte Funktionen zb. printf durch andere ersetzt, die schneller sein sollen. Das kann man unterbinden, zb. mit -fno-builtin (the big gun) oder selektiv mit -fno-builtin-<funktion>. In diesem Fall also -fno-builtin-printf.

Wieder was dazugelernt.

[ - Answer - Quote - Direct link - ]

2004-04-02, 09:19 h

Solar
Posts: 3680
User

Zitat:
Original von gni:
putchar ist keine ANSI/ISO Funktion und deswegen nicht Teil von libnix...

Da muß ich Dich enttäuschen... putchar() ist Teil des Standards, und definiert als "equivalent to putc with the second argument stdout"...

[ - Answer - Quote - Direct link - ]

2004-04-02, 11:59 h

gni
Posts: 1106
User

Zitat:
Solar:

Zitat:
Original von gni:
putchar ist keine ANSI/ISO Funktion und deswegen nicht Teil von libnix...
Da muß ich Dich enttäuschen... putchar() ist Teil des Standards, und definiert als "equivalent to putc with the second argument stdout"...

Tatsächlich, das war mir entgangen :-/ Da putchar als Makro in stdio.h definiert war, ist das Fehlen von putchar als Funktion nicht aufgefallen.

[ - Answer - Quote - Direct link - ]

2004-05-05, 14:22 h

gni
Posts: 1106
User

Zitat:
Original von gni:

Zitat:
Solar:

Zitat:
Original von gni:
putchar ist keine ANSI/ISO Funktion und deswegen nicht Teil von libnix...
Da muß ich Dich enttäuschen... putchar() ist Teil des Standards, und definiert als "equivalent to putc with the second argument stdout"...
Tatsächlich, das war mir entgangen :-/ Da putchar als Makro in stdio.h definiert war, ist das Fehlen von putchar als Funktion nicht aufgefallen.

Solar, Du hast bei Deinem Zitat etwas unterschlagen... putchar() ist genau wie putc() ein _Makro_! Das bedeutet doch wohl, das sowohl putchar() als auch putc() (und getc()) nicht als Funktion in einer Linker-Library sein müssen.

[ - Answer - Quote - Direct link - ]

2004-05-05, 14:49 h

Solar
Posts: 3680
User

Zitat:
Original von gni:

Solar, Du hast bei Deinem Zitat etwas unterschlagen... putchar() ist genau wie putc() ein _Makro_! Das bedeutet doch wohl, das sowohl putchar() als auch putc() (und getc()) nicht als Funktion in einer Linker-Library sein müssen.

Der Linker hat ja auch keine "unresolved reference" gemeldet, sondern "can't find reference". Ich würde hier eher vermuten, das GCC bei Optimierung -O1 aus printf("n") das "billigere" putchar('n') macht, und sich dann irgendwo verhaspelt.

Mein Zitat bezog sich nur darauf, das putchar() sehr wohl Teil des Standards ist; nicht auf die eigentliche Fehlerursache. ;-)

[ - Answer - Quote - Direct link - ]

2004-05-05, 15:18 h

gni
Posts: 1106
User

Zitat:
Original von Solar:

Zitat:
Original von gni:
Solar, Du hast bei Deinem Zitat etwas unterschlagen... putchar() ist genau wie putc() ein _Makro_! Das bedeutet doch wohl, das sowohl putchar() als auch putc() (und getc()) nicht als Funktion in einer Linker-Library sein müssen.
Der Linker hat ja auch keine "unresolved reference" gemeldet, sondern "can't find reference". Ich würde hier eher vermuten, das GCC bei Optimierung -O1 aus printf("n") das "billigere" putchar('n') macht, und sich dann irgendwo verhaspelt.

Macht GCC3 ja auch. Das funktioniert aber nur wenn putchar auch als Linker-Funktion existiert. Da die Man-Page es aber als Makro definiert, muss es nicht als "echte" Funktion existieren. Entweder GCC hat ungültige Annahmen oder Funktions-Makros müssen auch als echte Funktionen da sein.

Zitat:
Mein Zitat bezog sich nur darauf, das putchar() sehr wohl Teil des Standards ist; nicht auf die eigentliche Fehlerursache. ;-)

Ja, da hatte ich mich vertan.

[ - Answer - Quote - Direct link - ]

2004-05-05, 15:39 h

Solar
Posts: 3680
User

Zitat:
Original von gni:

Entweder GCC hat ungültige Annahmen oder Funktions-Makros müssen auch als echte Funktionen da sein.

Muß nicht, aber darf.

Es steht einer Implementierung frei, eine als Macro spezifizierte Funktionalität auch als Funktion anzubieten. In dem Moment, wo eine Implementierung dies tut, darf sie auch davon ausgehen.

Evtl. ist hier ein Teil der Implementierung geändert worden, der andere aber nicht. Ich bin beim Thema gcc-auf-Amiga nicht so drin... laufen hier evtl. Library- oder Header-Versionen zwischen GCC und ixemul auseinander oder so ein Keks?

[ - Answer - Quote - Direct link - ]

-1-

[ - Post reply - ]

amiga-news.de Forum > Programmierung > GCC 3.3

[ - Search - New posts - Register - Login - ]