Ich versuche ein altes Projekt mit avr-gcc zu compilieren und laufe auf
sehr merkwürdige Fehler.
Der Compiler ist avr-gcc (GCC) 4.8.2 mit Eclipse Version: Mars.1 Release
(4.5.1) Build id: 20150924-1200
Es ist die erste Zeile mit Fehler, es folgen weitere Merkwürdigkeiten.
Die Fehlermeldungen lauten:
Das ist eine Fehlermeldung von der Syntaxprüfung des Editors. Der kann
nicht alle Includes auflösen. Das Projekt wird vermutlich trotzdem
compilieren.
Irgendwo in den Optionen kannst du die Syntaxprüfung des Editors
ausschalten, dann verschwinden all diese Falschmeldungen.
Oliver
Öffne die Projekteinstellungen, ändere die CPU auf irgendeinen anderen
Wert, klick auf OK, öffne die Projekteinstellungen wieder, stell sie
wieder zurück auf den richtigen Wert, klick wieder auf OK und das
Problem sollte weg sein.
Ist ein alter Bug im AVR-Plugin, seit Jahren schon.
Bernd K. schrieb:> klick wieder auf OK und das Problem sollte weg sein.
Leider nicht. Der einzige Unterschied ist, dass der Fehler eine Zeile
höher gerutscht ist.
Es sieht so aus, als würde er keines der AVR-Typspezifischen Defines
kennen, obwohl dieser Test anschlägt:
1
#ifdef TWPS0
2
#error TWPS0 ist definiert
3
#endif
Zudem werden sämtliche typedefs aus stdint.h, wie z.B. uint8_t, als
unbekannt moniert.
Bei mir wurde es mit jeder Eclipse Version schlimmer.
Deswegen bin ich irgendwann stehengeblieben und zwar bei der
Version wo man einmal die CPU wechseln muss ;)
Kann bei Interesse morgen mal die Version raussuchen. Das avr plugin
wird ja leider nicht mehr gepflegt...
Deaktivier doch einfach die Eclipse-Syntaxprüfung, und alles ist gut.
Die wird tatsächlich von Version zu Version katastrophaler.
Der Compiler sagt einem schon beim compilieren, wenn wirklich was nicht
stimmt.
Oliver
Oliver S. schrieb:> Da kannst du den Wahnsinn sogar feinjustieren :)
Ich hab erst mal alles abgeklemmt und das hatte zumindest zu Folge, dass
keine Fehlermeldungen mehr kommen und der Compiler glatt durch läuft...
Eclipse ist eine eierlegende Wollmichsau, die vor lauter Wollmilcheiern
nicht mehr laufen kann.
Nur der 64-Bit-Firefox ist lahmarschiger.
Uhu U. schrieb:> und der Compiler glatt durch läuft...
Der Compiler läuft auch mit den Fehlermeldungen glatt durch. Die
Eclipse-Syntaxprüfung ist völlig unabhängig vom Compiler. Und am Ende
zählt eh nur, was der sagt.
Oliver
Oliver S. schrieb:> Deaktivier doch einfach die Eclipse-Syntaxprüfung
Das ist grober Unfug. Wenn Eclispe die Includes nicht findet dann kann
er auch gleich Notepad statt Eclispe nehmen denn dann wird auch das
komplette Code-Assist und die Navigation im Code nicht mehr gehen, wozu
braucht er dann überhaupt noch ne IDE?
Der korrekte Weg ist das einmal richtig zu konfigurieren so daß in
Zukunft immer alles geht anstatt einfach alle Features zu deaktivieren
derentwegen man das Produkt überhaupt verwendet.
Bernd K. schrieb:> Das ist grober Unfug. Wenn Eclispe die Includes nicht findet dann kann> er auch gleich Notepad statt Eclispe nehmen denn dann wird auch das> komplette Code-Assist und die Navigation im Code nicht mehr gehen, wozu> braucht er dann überhaupt noch ne IDE?
Ist es nicht. Grober Unfug ist Eclipse mit seiner aberwitzigen
Hintergrundwerkelei. Das Ding ist ätzend langsam, nur Firefox ist
schlimmer...
Beide Programme leben vom Hauptspeicher. Wenn man damit nicht geizt,
dann klappt das schon. Und man muß eigentlich nur eine Stange Raufware
nicht kaufen, schon ist's bezahlt. Schreibt ein Nichtraucher aus einer
halbrauchenden Familie.
Carl D. schrieb:> Beide Programme leben vom Hauptspeicher. Wenn man damit nicht geizt,> dann klappt das schon.
Meine Mühle hat 16 GB, davon frei sind meistens > 50% - was daran da
"geizig" sein soll, musst du erklären.
> Schreibt ein Nichtraucher aus einer halbrauchenden Familie.
Was soll das denn?
Bernd K. schrieb:> Der korrekte Weg ist das einmal richtig zu konfigurieren so daß in> Zukunft immer alles geht
Ist ja prinzipiell richtig, nur leider im Falle von Eclipse (und
besonders der bescheuerten Syntaxprüfung) ein frommer Wunschtraum.
Uhu U. schrieb:> Bernd K. schrieb:>> klick wieder auf OK und das Problem sollte weg sein.>> Leider nicht. Der einzige Unterschied ist, dass der Fehler eine Zeile> höher gerutscht ist.
Oliver
Oliver S. schrieb:> Ist ja prinzipiell richtig, nur leider im Falle von Eclipse (und> besonders der bescheuerten Syntaxprüfung) ein frommer Wunschtraum.
Komisch, bei den meisten Leuten ist der der Traum Realität, so zum
Beispiel auch bei mir: im Verlauf des letzen Jahres hab ich Eclipse auf
mindestens 4 verschiedenen neuen Rechnern neu aufgesetzt (1*Kubuntu,
2*Win7, 1*Win10) und überall manifestierte sich der Traum gleich im
ersten Anlauf ganz von selbst in der Realität.
> Carl D. schrieb:>> Beide Programme leben vom Hauptspeicher. Wenn man damit nicht geizt,>> dann klappt das schon.>> Meine Mühle hat 16 GB, davon frei sind meistens > 50% - was daran da> "geizig" sein soll, musst du erklären.>>> Schreibt ein Nichtraucher aus einer halbrauchenden Familie.>> Was soll das denn?
1. Bei mir läuft Eclipse und Firefox parallel auf 4Gb ohne unzumutbare
Wartezeiten. OS ist Linux. Und ja ich hab das auch Windows7 im Einsatz,
da sollte es eher das Doppelte sein.
2. Es ging (im nichtzitierten Text) um einen Vergleich der Kosten für
Speicher mit (für manche) gängigen Verbrauchswaren. Kann man mit dem
rausgerupften Textfragment nur nicht erkennen.
Zu "16G und trotzdem langsam": Eclipse hat eine Konfigurationsdatei für
den Start der Java-VM. Wenn da noch der Defaultwert von 512Mb drinsteht,
dann kann man das durch mehr RAM nicht ändern. Da muß man mit einem
Texteditor ran. Wie das geht steht z.B. hier:
http://stackoverflow.com/questions/15313393/how-to-increase-application-heap-size-in-eclipse
Carl D. schrieb:> 2. Es ging (im nichtzitierten Text) um einen Vergleich der Kosten für> Speicher mit (für manche) gängigen Verbrauchswaren. Kann man mit dem> rausgerupften Textfragment nur nicht erkennen.
Sorry, es ging um völlig irrelevante und falsche Unterstellungen und
damit vollkommen am Thema vorbei und was du von irgendwelchen
Suchtmitteln hälst, interessiert nicht.
Carl D. schrieb:> Zu "16G und trotzdem langsam": Eclipse hat eine Konfigurationsdatei für> den Start der Java-VM. Wenn da noch der Defaultwert von 512Mb drinsteht,> dann kann man das durch mehr RAM nicht ändern. Da muß man mit einem> Texteditor ran. Wie das geht steht z.B. hier:
Warum schreibst du dann erst so einen hanebüchenen Blödsinn? Warum nicht
gleich so?
Ich habe den Speicher auf 2GB gesetzt - schneller ist das Teil jetzt,
aber von wirklich schnell ist es noch weit entfernt. Ich sehe noch immer
das Geruckel im File Explorer.
Außerdem ist das Ursprungsproblem - hunderte völlig blödsinniger
Fehlermeldungen von der Eclipse-Syntaxprüfung - noch immer da, wenn ich
die Syntaxprüfung einschalte.
Wie bekomme ich die weg?
Ich hoffe, dir ist klar, dass es sich um AVR-Projekte mit dem AVR-Plugin
dreht - bei Linux-Projekten gibts den Spuk nicht.
> Ich hoffe, dir ist klar, dass es sich um AVR-Projekte mit dem> AVR-Plugin dreht - bei Linux-Projekten gibts den Spuk nicht.
Ich schrieb: OperatingSystem ist Linux.
Was ich nicht schrieb: auch ich verwende das AVR-Plugin und ja ich kenne
dieses Phänomen auch und ich lese hier mit, um eventuell Infos abstäuben
zu können. Denn bisher hab ich auch nach der Devise "nur der GCC sagt
die Wahrheit" gearbeitet. Leider war ich heute Abend zu faul, irgend was
von dem geschriebenen auszuprobieren.
(Und es war nicht beabsichtigt, irgend eine Genusshandlung zu
kritisieren, es ging rein um den Vergleich von Geldbeträgen)
Der Tipp, vorübergehend den Controllertyp zu ändern, hats jedenfalls
nicht gebracht. Bleibt nur, den - m.A. auch völlig überflüssigen -
Syntax-Mist einfach abzuschalten, oder das Plugin zu reparieren.
Carl D. schrieb:> Wenn da noch der Defaultwert von 512Mb drinsteht, dann kann man das durch> mehr RAM nicht ändern. Da muß man mit einem Texteditor ran.
Ja, ein Hoch auf die superautomatisierte IDE. ;-)
(sorry, konnt ich mir nicht verkneifen)
Uhu U. schrieb:> Bleibt nur, den - m.A. auch völlig überflüssigen -> Syntax-Mist einfach abzuschalten, oder das Plugin zu reparieren.
Der völlig überflüssige Syntax-Mist macht nicht nur beim AVR-plugin
Probleme. Mit aktuellem C++11/14 hat die auch so ihre Probleme. Gut
gedacht, schlecht gemacht. Wie leider vieles an Eclipse.
Oliver
Oliver S. schrieb:> Gut gedacht, schlecht gemacht.
Das ist noch nichtmal gut gedacht. Das ist einfach mit Brachialgewalt
was herfantasiert, was keiner braucht.
Einmal im Projekt sauber den Include Pfad unter C/C++ General -> Paths
and Symbols setzen und danach den Index neu aufbauen, dann sollte
Schluss mit den Fehlern sein. Ansonsten ist an anderer Stelle etwas grob
verbastelt. Syntaxprüfung deaktivieren ist Unsinn, dann kann man auch
ganz auf Eclipse verzichten.
no-use-for-a-name schrieb:> Einmal im Projekt sauber den Include Pfad unter C/C++ General -> Paths> and Symbols setzen und danach den Index neu aufbauen, dann sollte> Schluss mit den Fehlern sein.
Dann verrate mir mal, was ich dort - außer den im Anhang aufgeführten
Pfaden noch alles hinterlegen soll. Die Pfade existieren und enthalten
die Dateien, die angeblich nicht gefunden werden.
> Syntaxprüfung deaktivieren ist Unsinn, dann kann man auch> ganz auf Eclipse verzichten.
Ich bin 40 Jahre ohne solche Gimmics ausgekommen und sehe schlicht
keinen Sinn darin. Schon gar nicht, wenn dadurch die normale Arbeit am
Programmtext gestört wird, z.B. durch ruckeln.
Uhu U. schrieb:> Ich bin 40 Jahre ohne solche Gimmics ausgekommen und sehe schlicht> keinen Sinn darin. Schon gar nicht, wenn dadurch die normale Arbeit am> Programmtext gestört wird, z.B. durch ruckeln.
Eine sehr gute Frage! :-))
Ich benutze einfach nur Kate mit Syntax Highlighting und C++ Helper
Plugin und komme damit sehr gut zurecht.
Das Einzige was ich noch vermisse wäre eine Anzeige von
Funktionsargumenten, wenn man eine Funktion beginnt zu tippen ...
Uhu U. schrieb:> Ich bin 40 Jahre ohne solche Gimmics ausgekommen und sehe schlicht> keinen Sinn darin.
Warum verwendest Du es dann und machst diesen albernen als Frage
getarnten Eclipse-Bashing-Thread auf um Dich darüber auszuheulen? Bleib
doch einfach bei dem Editor den Du schon seit 40 jahren verwendest.
no-use-for-a-name schrieb:> Einmal im Projekt sauber den Include Pfad unter C/C++ General ->> Paths> and Symbols setzen
Du kennst Dieter Nuhr?
Also.
Das Problem hat bei AVR-Programmen mit den Pfaden nichts zu tun.
Oliver
_AVR_ATmega328P_ - genau das, was ich eingestellt habe.
Ctrl + Linksklick auf #include <stdint.h> führt mit einem
Zwischenschritt auf den Header, der die typedefs für uint8_t usw.
enthält.
Das hält Ecplipe aber nicht davon ab, sämtliche Symbole, die dort
definiert und nicht ausgegraut sind, als undefiniert zu melden.
Was sagt:
Index -> search for unresolved includes
Hast Du irgendwas an den Indexer-Einstellungen verändert?
> ein altes Projekt
Wie alt? Was passiert wenn Du mal ein neues Projekt erzeugst (zwei mal
Target MCU Type ändern nicht vergessen)?
Wenn Du die Fehler in der Problems Liste einfach löschst und dann auf
Index->Rebuild gehst, kommen sie dann wieder? Tauchen die angeblich
fehlenden Symbole auch nicht im Autocomplete auf?
Ich habe Eclipse Mars.1 und AVR-Plugin 2.4.1 hier unter Kubuntu 15.10
und ich kann beim besten Willen auch durch mutwilliges Verstellen der
Indexer-Einstellungen deinen Fehler nicht repoduzieren, auch nicht mit
älteren Projekten die noch von Luna stammen. Sobald es den includes
folgen kann hat es auch alle darin deklarierten Symbole gefressen. Ich
kann mich auch nicht erinnern jemals in all den Jahren je so etwas
schräges erlebt zu haben, entweder er findet sie gar nicht oder er
findet sie und dann geht es aber auch.
Womöglich hast Du irgendwas grundlegendes kaputtkonfiguriert oder
zerschossen, vielleicht hilft ja ein Neubeginn mit einem frischen
jungfräulichen Eclipse, und von dann an bei jeder Konfiguration die vom
Default abweicht selbiges irgendwo niederschreiben, zusammen mit
Begründung warum es erforderlich war. Das spart Zeit und kann sich
später als hilfreich erweisen.
Nochwas:
Man kann bei einzelnen Dateien einige Einstellungen separat ändern
(also die Projekteinstellungen überschreiben), oft versehentlich indem
man auf der Datei rechte Maus->Properties verwendet anstatt das selbe am
ganzen Projekt zu machen.
Dann taucht ein kleiner Schlüssel rechts oben am Datei-Icon auf um
anzuzeigen daß für diese Datei abweichende Einstellungen gelten.
Abhilfe: Für jede betroffene Datei: Rechte Maus -> Ressource
Configurations -> Reset to default
Danach: Index -> Rebuild.
Bernd K. schrieb:> Was sagt:>> Index -> search for unresolved includes
Aha, jetzt kennt er die Symbole, mault aber jeden //-Kommentar mit "Line
Comments '//' are not allowed" an. OK, das kann man konfigurieren.
Jetzt sind die Fehler weg - danke für die Nachhilfe.
> Hast Du irgendwas an den Indexer-Einstellungen verändert?
Nein. Das ist alles, wie es vor 3 Jahren war. Schon erstaunlich, dass er
zwar gemerkt hat, dass das Projekt von einer anderen Version stammt,
aber der Index offenbar einfach übernommen wird.
Den Controller-Typ habe ich schon mehrfach geändert.
> Ich habe Eclipse Mars.1 und AVR-Plugin 2.4.1 hier unter Kubuntu 15.10
Ich auch, allerdings unter Mint 17. Das Projekt stammt von Luna.
Also nochmal zusammenfassend, was ich gemacht habe
1. Controllertyp geändert → apply, dann dasselbe zurück
2. Project → C/C++ Index → Rebuild
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
Screenshot.png
(14 KB)
