Forum: Compiler & IDEs g++ (ver 4.3) uisp compiler bricht ab


von msnider (Gast)


Lesenswert?

hallo leute,

habe versucht meine Entwicklungsumgebung auf das neue Dist(11.1) von 
SUSE
zu erneuern. Alles klappte bis zum UISP allerletzte Release 2005
Der Kompiler G++ 4.3 bricht ab mit der Meldung deprecated string 
constant
Zeile in der AVR.C
const char* TAvr::irgendwas[] = {"foo","bar","...",NULL};

Meine Frage ist, hat jemand schon Erfahrung auf dem 4.3 Compiler mit 
UISP.
Oder gibt es eine Compileroption die dieses Warning, das schließlich
zum ERROR mutiert, abstellt. So eine Art 
Rückwärtskompatibilitätschalter?

Arbeite zur Zeit noch mit einer UISP, die ich auf einem anderen System
kompiliert habe und mit der Pinzette in die neue Umgebung installiert 
habe. Würde dies aber gerne ändern, da ich alte Liberies mit schleppen 
muß.

Danke im Voraus an die Community

Michel

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

UISP wird doch schon seit vielen Jahren nicht mehr gepflegt.  Nimm
AVRDUDE.

von msnider (Gast)


Lesenswert?

hallo joerg,

das waere meine zweite Option gewesen. Gebe aber normalerweise nicht so 
schnell auf. Habe das UISP immer gerne benutzt und gute Erfahrung damit 
gemacht.

Aber sorry, habe meine Anfrage wohl ins falsche Forum gestellt. Hat
ja nichts mit dem AVR zu tun, sonder mit gcc. Bin ins andere Forum 
umgezogen.

Danke Michel

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

msnider wrote:

> Gebe aber normalerweise nicht so
> schnell auf. Habe das UISP immer gerne benutzt und gute Erfahrung damit
> gemacht.

Dann pflege es halt weiter.  Es gibt aber mittlerweile nichts mehr,
was UISP kann, das AVRDUDE nicht auch könnte, und im Gegensatz zu
UISP ist AVRDUDE halt nicht verwaist.

> Aber sorry, habe meine Anfrage wohl ins falsche Forum gestellt. Hat
> ja nichts mit dem AVR zu tun, sonder mit gcc. Bin ins andere Forum
> umgezogen.

Das ist nach dem Beginn der Diskussion nicht sehr sinnvoll.  Ich habe
deinen Thread daher verschoben und den neuen mal gelöscht.  So bleibt
der Zusammenhang wenigstens gewahrt.

von Karl H. (kbuchegg)


Lesenswert?

Wobei sich schon dir Frage stellt, was bei

const char* TAvr::irgendwas[] = {"foo","bar","...",NULL};

denn die "depracted string constant" ist.
Er wird doch nicht das NULL meinen?

Also: echten Code herzeigen. Ich glaub dir nicht, dass hier tatsächlich 
die Strings "foo" und "bar" und "..." in eine Array verpointert werden.
Schlimmstenfalls mal die Zeile umbrechen:


const char* TAvr::irgendwas[] = {
       "foo",
       "bar",
       "...",
       NULL
};

Dann kriegt man über die Zeilennummer der Fehlermeldung mehr Info.

von msnider (Gast)


Lesenswert?

Hallo Karl heinz,

doch er meinte das NULL, habe es bis auf genau diese Stellen
eingrenzen können. Da ich aber nach seit fünf Jahren auf dem
alten Kernel unter Gcc 3.X.X programmiere und nach dem Upgrade
diese Kompilerfehler nicht nur beim UISP auftreten, ackere ich nun
die manpages und all den Dokubereich des gcc_4.X.X durch,
um mich in dieser mir neuen Umgebung zurecht zufinden. Dank
an Joerg, werde in Zukunft grössere Sorgfalt bei der Wahl meiner
Beiträge zum jeweiligen Forum walten lassen.

Danke Michel

von yalu (Gast)


Lesenswert?

> Zeile in der AVR.C
> const char* TAvr::irgendwas[] = {"foo","bar","...",NULL};

Diese Zeile kann ich nirgends in Avr.C finden. Auch sonst wird nirgends
eine Variable namens "irgendwas" benutzt. Des Weiteren ist es völlig
korrekt, ein char * mit NULL zu initialisieren.

So liefert bspw.
1
const char* TAvr::segment_names[] = {"flash", "eeprom", "fuse", NULL};

(Zeile 129 in Avr.C) bei mir (GCC 4.3.3) weder einen Fehler noch eine
Warnung.

Eine (wegen -Werror als Fehler ausgegebene) Warnung erhalte ich aber in
der Initialisierung von TAvr::parts in den Zeilen 46-127, weil dort ein
char * (ohne const) mit einer Stringkonstanten initialisiert wird.
Ändere die Zeile 145 von Avr.h einfach in
1
    const char* name;

Eine weitere Warnung liefert die Zeile 422 in Stk500.C. Tu dem Compiler
den Gefallen und klammere den <<-Teilausdruck, dann sind alle Warnungen
weg und das Programm kompiliert anstandslos.

Alternativ kannst du in src/Makefile.am bzw. src/Makefile.in das -Werror
entfernen, so dass Warnungen vom Compiler nicht als Fehler behandelt
werden.

von msnider (Gast)


Lesenswert?

hallo leute,

danke YALU für deine Antwort , aber irgendwie hat er es doch mit der
NULL.

Diesmal etwas konkreter:

make  all-am
make[1]: Entering directory `/usr/local/atmel/uisp-20040311/src'
if g++ -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -MT AvrDummy.o -MD -MP -MF 
".deps/AvrDummy.Tpo" \
    -c -o AvrDummy.o `test -f 'AvrDummy.C' || echo './'`AvrDummy.C; \
  then mv -f ".deps/AvrDummy.Tpo" ".deps/AvrDummy.Po"; \
  else rm -f ".deps/AvrDummy.Tpo"; exit 1; \
  fi
make[1]: Leaving directory `/usr/local/atmel/uisp-20040311/src'
In file included from AvrDummy.h:31,
                 from AvrDummy.C:38:
Global.h: In member function ‘void TPt<TRec>::MkRef()’:
Global.h:43: error: ‘NULL’ was not declared in this scope
Global.h: In member function ‘void TPt<TRec>::UnRef()’:
Global.h:44: error: ‘NULL’ was not declared in this scope
Global.h: In constructor ‘TPt<TRec>::TPt()’:
Global.h:46: error: ‘NULL’ was not declared in this scope
Global.h: In member function ‘TRec* TPt<TRec>::operator->() const’:
Global.h:57: error: ‘NULL’ was not declared in this scope
Global.h: In member function ‘TRec& TPt<TRec>::operator*() const’:
Global.h:58: error: ‘NULL’ was not declared in this scope
Global.h: In member function ‘TRec& TPt<TRec>::operator[](int) const’:
Global.h:59: error: ‘NULL’ was not declared in this scope
make[1]: *** [AvrDummy.o] Fehler 1
make: *** [all] Fehler 2


Was will er nur mit der NULL?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

msnider schrieb:

> Was will er nur mit der NULL?

Da fehlt wohl ein <stdio.h> oder <stdlib.h>.

von Stefan E. (sternst)


Lesenswert?

Du programmierst in C++, da solltest du dir dieses NULL eh abgewöhnen. 
Wenn du eine Null haben willst, dann schreibe auch eine Null.
1
const char* TAvr::segment_names[] = { "flash", "eeprom", "fuse", 0 };

Und wenn du partout NULL benutzen willst, musst du <cstddef> einbinden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Stefan Ernst schrieb:
> Du programmierst in C++, da solltest du dir dieses NULL eh abgewöhnen.
> Wenn du eine Null haben willst, dann schreibe auch eine Null.

NULL ist ja keine Null, sondern soll eigentlich nur kenntlich machen,
dass es im Kontext eines Zeigers benutzt wird.  Syntaktisch kann man
das natürlich auch als 0 schreiben (die Umwandlung in einen Nullzeiger
ist implizit), aber (je nach persönlichem Geschmack) zeigt NULL dem
Leser an, dass das ein Zeiger sein soll.

Auch in C ist 0 eine völlig legale Variante, um den Makro NULL zu
implementieren.  (In C ist außerdem (void *)0 legal, in C++ meines
Wissens nicht.)

von Stefan E. (sternst)


Lesenswert?

Gut, ich gebe zu, mit den Details dazu bin ich nicht völlig vertraut. 
Ich halte mich da einfach an Stroustrup:
1
In C war es populär, ein Makro NULL zu definieren, um den Nullzeiger
2
zu repräsentieren. Durch die engere Typprüfung von C++ führt die Benutzung
3
der einfachen 0 anstelle des NULL-Makros zu weniger Problemen.

von yalu (Gast)


Lesenswert?

> make[1]: Entering directory `/usr/local/atmel/uisp-20040311/src'

Autsch, du bist ja wirklich ein Archäologe ;-). Mein letzter Beitrag
bezog sich auf die "neueste" Version 20050207.

> aber irgendwie hat er es doch mit der NULL.

Diesmal hat das aber nichts mit der Initialisierung von Stringvariablen
zu tun. Die NULL ist weder Global.h noch in einer includeten Datei
deklariert. Wenn du in Global.h nach dem
1
#include <assert.h>

noch ein
1
#include <stddef.h>

einfügst, ist auch dieses Problem behoben.

Trotzdem würde ich Jörgs Vorschlag folgen und auf Avrdude umsteigen.
Dieser kompiliert auch ohne Patches und unterstützt mittlerweile 78
AVR-Typen, während der aktuelle Uisp gerade mal 32 (die von dir gewählte
Version sogar nur 30) kann.

von msnider (Gast)


Lesenswert?

Hallo YALU ,JOERG und STEFAN.....

Ich danke Euch allen und besonders YALU. Die <stddef.h> war es.

Mein Versuch war :

#define NULL (void *)0 //was so natürlich nicht funktionierte.

eher,

#define NULL ((void *)0) was aber zu einem
<<invalid conversion from void* to const char*>> führte.
Joerg hat ja darauf schon hingewiesen.

Aber richtig wäre dann wohl gewesen:

#undef NULL -> vermeidet redefinition Warnung
#define NULL 0 -> C++ Style

oder gleich die <stddef.h> includen, wie YALU wohl richtig
angemerkt hat.

Die Warnung in der Stk500.C ist die fehlende Klammer um das
shift, wie YALU bemerkte.

Zum Punkt Archäologie : Habe natütlich die Version
genommen, die ich erfolgreich auf einem 2.4.x- Kernel
compilieren konnte und auch produktiv eingesetzt habe.
Schien mir am sinnvollsten.

Zum Punkt unterstützte AVRs. Ich habe bis jetzt nur mit M8
und 2313 gearbeitet, deshalb hatte ich keinen Bedarf nach
mehr Hardware-Support.

Werde aber euren Rat befolgen und demnächst den DUDE nehmen.
Schade eigentlich das die Jungs die Sache eingestell haben,
war und ist für mich ein super Tool.

Also nochmals danke an Euch alle.

Gruß Michel

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.