@Jörg Wunsch
Ich habe versucht, simulavr-0.1.2.6 unter Ubuntu 10.04 (gcc version
4.4.3 (Ubuntu 4.4.3-4ubuntu5)) zu compilieren - leider mit mäßigem
Erfolg:
Uhu Uhuhu schrieb:> @Jörg Wunsch
Ich bin zwar nicht Jörg Wunsch, aber der hat sich vor ein paar Tagen
schon genug mit dir bemüht und hat jetzt mal eine Pause verdient ;-)
> Ist der Compiler schärfer geworden, daß er einen mit -Werror sofort> rauskickt, oder ist der Quelltext kaputt?
Es ist (und war schon immer) genau der Sinn von -Werror, dass Warnungen
wie Fehler behandelt werden, so dass ein Build mit Make auch schon bei
Warnungen abgebrochen wird.
Du kannst
- im Quellcode die angeprangerten Variablen entfernen,
- im Makefile bzw. im configure das -Werror oder -Wall entfernen oder
- nach dem -Wall ein -Wno-unused einfügen,
um das Problem zu beheben.
Yalu X. schrieb:> Ich bin zwar nicht Jörg Wunsch, aber der hat sich vor ein paar Tagen> schon genug mit dir bemüht und hat jetzt mal eine Pause verdient ;-)
Sieh dir den Changelog von simulavr an...
> Es ist (und war schon immer) genau der Sinn von -Werror, dass Warnungen> wie Fehler behandelt werden,
Da wär ich jetzt nicht draufgekommen...
> - im Makefile bzw. im configure das -Werror oder -Wall entfernen oder
OK, configure ist der Schlüssel zu Lösung und man sollte die -Wno-unused
in der Distribution dort anbringen (config:7216).
Die Makefiles zu ändern ist schier ein Faß ohne Boden und zudem der
falsche Ansatz - das hatte ich versucht.
Nachtrag: -Wno-unused beseitigt das Problem nicht.
Uhu Uhuhu schrieb:>> Es ist (und war schon immer) genau der Sinn von -Werror, dass Warnungen>> wie Fehler behandelt werden,>> Da wär ich jetzt nicht draufgekommen...
Wieso fragst du dann:
> Ist der Compiler schärfer geworden, daß er einen mit -Werror sofort> rauskickt
?
> OK, configure ist der Schlüssel zu Lösung und man sollte die -Wno-unused> in der Distribution dort anbringen (config:7216).
Bei mir ist es die Zeile 7214, die geändert werden muss (ebenfalls
simulavr-0.1.2.6).
> Die Makefiles zu ändern ist schier ein Faß ohne Boden und zudem der> falsche Ansatz - das hatte ich versucht.
Deswegen der Hinweis mit configure. Aber auch configure wird wie die
Makefiles automatisch generiert. Deswegen wäre die saubere Lösung,
configure.ac zu ändern und anschließend einen autoconf zu machen. Nur
hat die Autotools nicht jeder installiert, weswegen mir dieser Vorschlag
als zu kompliziert für dich erschien. Nicht, dass du noch anfängst,
diese Tools ebenfalls from Scratch zu bauen ;-)
> Nachtrag: -Wno-unused beseitigt das Problem nicht.
Bei mir baut's damit fehlerfrei :)
Uhu Uhuhu schrieb:> Das -Werror sieht mir stark nach einem Schnellschuß 3 Sekunden vor dem> Release aus. Damit ist der Compiler sicher nicht durchgelaufen.
Natürlich ist der damit durchgelaufen. Allerdings ist das Zeug
seit mindestens 3 Jahren aus der Pflege raus, sodass Dinge, die
Compiler heutzutage monieren, damals aber nicht gesehen haben, davon
einfach unberücksichtigt sind.
Aber wart' mal: config_scanner.c ist doch automatisch via lex von
config_scanner.l generiert. Wenn das flex da eine unbenutzte Variable
reinschmeißt, dann kann simulavr dafür ohnehin herzlich wenig tun.
Mein Tipp wäre auch, das -Werror aus dem configure rauszukicken.
Jörg Wunsch schrieb:> Allerdings ist das Zeug> seit mindestens 3 Jahren aus der Pflege raus, sodass Dinge, die> Compiler heutzutage monieren, damals aber nicht gesehen haben, davon> einfach unberücksichtigt sind.
Sowas in der Art war meine erste Vermutung...
> Mein Tipp wäre auch, das -Werror aus dem configure rauszukicken.
-Werror in einem Distributiionspaket ist wohl auch nicht unbedingt
sinnvoll, wenn es sich nicht gerade um sicherheitsrelevante Software
handelt. Die ist gut für Entwickler.
Ich will mir das Ding mal näher ansehen, mal sehen, wie aufwendig und
wie lohnend es ist, z.B. die 48/88/168 - Linie einzubauen. Gibt es noch
irgendwo nähere Informationenzu dem Bereich
avr-gdb/simulavr/simulavr-disp?
Uhu Uhuhu schrieb:> -Werror in einem Distributiionspaket ist wohl auch nicht unbedingt> sinnvoll, wenn es sich nicht gerade um sicherheitsrelevante Software> handelt. Die ist gut für Entwickler.
Mag sein, war halt so die Idee von Ted Roth, der das Teil seinerzeit
entwickelt und gepflegt hatte.
> Ich will mir das Ding mal näher ansehen, mal sehen, wie aufwendig und> wie lohnend es ist, z.B. die 48/88/168 - Linie einzubauen. Gibt es noch> irgendwo nähere Informationenzu dem Bereich> avr-gdb/simulavr/simulavr-disp?
Es gibt eine (automatisch generierte) Doku zu den Interna des
Simulators.
Ich würde mich an deiner Stelle allerdings mal beim Nachfolgeprojekt
umsehen. Das hieß mal simulavrxx, wird jetzt aber allgemein auch
einfach simulavr genannt. Leider haben die Jungs aber keine release
policy, sodass du wohl nicht umhin kommen wirst, da aus irgendeinem
git-Repo dir den aktuellen Sourcecode selbst zu holen. Dafür könnte
es sein, dass die ATmegaX8-Reihe dort schon eingebaut ist.
Interessant. Über die simulavrxx war ich auch schon gestolpert, aber da
die neuste Version davon älter ist, als die neuste von simulavr, war ich
erst mal davon ausgegangen, daß der xx im simulavr aufgegangen ist.
Ist das Nachfolgeprojekt http://avrs.sourceforge.net/ ?
Das Ding ist in Java geschrieben...
Stimmt es, daß beim simulavr 0.1.2.6 nur lowlevel debugging geht? (Stand
bei Heise)
Uhu Uhuhu schrieb:> Ist das Nachfolgeprojekt http://avrs.sourceforge.net/ ?
Sieht stark danach aus:
> Automatic Voice Relay System is a voice-linking system for Amateur Radio> that uses APRS and the APRS-Internet System as a signaling channel.> AVRS contains a complete set of APRS parsers in a clean, object-oriented> Java-Bean library.
Uhu Uhuhu schrieb:> Über die simulavrxx war ich auch schon gestolpert, aber da> die neuste Version davon älter ist, als die neuste von simulavr, war ich> erst mal davon ausgegangen, daß der xx im simulavr aufgegangen ist.
Naja, wie schon geschrieben, das Bauen eines Releases ist irgendwie
nicht das, was die Jungs sich da auf die Fahnen geschrieben haben.
Schade eigentlich.
Dass ich vom alten simulavr gelegentlich nochmal ein Release gemacht
habe, liegt einfach nur an solchen Dingen wie dem, worüber du gerade
stolperst: wenn der Sourcecode mal wieder partout nicht mehr mit
aktuellen Compilern verträglich ist, rolle ich schon nochmal einen
Release davon, auch wenn der Code an sich nicht mehr gepflegt wird.
Er wird aber in der avr-libc für die regression test suite noch
benutzt, von daher habe ich ein Interesse daran, dass er compilierbar
bleibt.
Uhu Uhuhu schrieb:> Stimmt es, daß beim simulavr 0.1.2.6 nur lowlevel debugging geht? (Stand> bei Heise)
Hätte auch bei BILD stehen können. ;-)
Was zum Geier sollte es denn den Simulator interessieren, auf welcher
Ebene der Debugger ansetzt?
Vermutlich haben sie das simulavr-disp (das ja in einem separaten xterm
rein den Maschinenzustand, also Register, RAM, ROM anzeigt) da als
Kriterium benutzt. Aber das ist ja nur eine zusätzliche Hilfe (und
ja, die ist in der Tat vor allem beim Debuggen von Assemblercode
interessant), das kann und soll nicht den regulären Debugger ersetzen.
Jörg Wunsch schrieb:> Naja, wie schon geschrieben, das Bauen eines Releases ist irgendwie> nicht das, was die Jungs sich da auf die Fahnen geschrieben haben.> Schade eigentlich.
Weißt du, wo das Repositorium von denen zu finden ist?
Uhu Uhuhu schrieb:> Jörg Wunsch schrieb:>> Naja, wie schon geschrieben, das Bauen eines Releases ist irgendwie>> nicht das, was die Jungs sich da auf die Fahnen geschrieben haben.>> Schade eigentlich.>> Weißt du, wo das Repositorium von denen zu finden ist?
Wenn du's nicht findest, melde dich auf der Mailingliste an und frag.
Die Jungs sollen ruhig mal merken, dass sie in Punkto "Kundenpflege"
doch ein wenig Nachholebedarf haben.
Jörg Wunsch schrieb:> Wenn du's nicht findest, melde dich auf der Mailingliste an und frag.
Dort scheint tote Hose zu sein. Versuche, sich zur Mailingliste
anzumelden, bleiben ohne jeden Effekt; keine EMail, kein Zugang.
Seltsam, das ist eine normale Mailman-verwaltete Liste, dafür bedarf
es eigentlich keinerlei humaner Interaktion (außer deiner).
Anyway, ich habe dir mal eine Einladung geschickt in die Liste.
Ja, allzu viel Traffic ist da wirklich nicht.
Uhu Uhuhu schrieb:> Wie wirkt die sich aus? Ich sehe unter> http://lists.gnu.org/archive/html/simulavr-devel/2011-05/index.html> leider keinerlei Bewegung.
In welchem Zeitraum? Es dauert von einer Liste bis ins Archiv. Bei GCC
sind's ein paar Minuten; bei der avr-libc kann's ein paar Stunden
dauern. Ist bei der Liste womöglich ähnlich. Hast du keine Mail
bekommen? Wenn du eine Mail zurückbekommst, haben die auch die anderen
Mitglieder.
Was macht eigentlich der Simpilator, der seit 7.0 im avr-gdb ist?
Ist das ne eigene Implementierung? Leider findet sich in der
avr-gdb-Doku praktisch überhaupt nix darüber; auch nicht über Zustand
oder was der alles (nicht) kann wie SFRs, IRQs, welche Derivate, etc.
Der ist mir schon mal auf die Füße gefallen für einen ATmega2560 für ein
funktionierendes (in avrtest) Programm.
Johann L. schrieb:> In welchem Zeitraum?
Vor 6 Tagen habe ich mich angemeldet - keine Reaktion
> Hast du keine Mail bekommen?
Nein
Jörg Wunsch schrieb:> Du solltest eine Mail bekommen haben, die dich auffordert, die Einladung> anzunehmen.
Bis jetzt nicht.
Mittlerweile habe ich einen tarball mit einem Stand von simulavrxx
gefunden. Die Files darin stammen allerdings von 12/2009.
Uhu Uhuhu schrieb:> Jörg Wunsch schrieb:>> Du solltest eine Mail bekommen haben, die dich auffordert, die Einladung>> anzunehmen.>> Bis jetzt nicht.
Dann solltest du mal dein Spamfilter überprüfen. Der Listserver von
gnu.org hat keine Probleme, ich habe eben nochmal probiert, mir selbst
eine Einladung zu senden.
Ich kann dich auch gern direkt da eintragen ohne Einladung, wenn du
willst. Hilft dir allerdings nichts, wenn dein Mailer irgendwie die
Mails von gnu.org nicht durchlässt.
Jörg Wunsch schrieb:> Dann solltest du mal dein Spamfilter überprüfen.
Fast... Es war eine TB Sortierregel, die alles, was von nongnu.org kam,
bei rdiff rdiff-backup-users einsortiert hat. Das war ein Schuß ins
Knie...
Thread beobachten
Seitenaufteilung abschalten