Hallo,
Da in dem anderen Thema Anfragen kamen, wie man avr-gcc unter Windows
selbst kompiliert und ich auch zwei E-Mails zu diesem Thema empfangen
habe, möchte ich einen Link bereitstellen, der den Zugang zu einem
Windows-Build von avr-gcc 4.5.0 ermöglicht.
Benutzung auf eigene Gefahr, ich kann nicht dafür garantieren, dass
fehlerfreier Code erzeugt wird.
Ich hoffe, dass dies mit den Nutzungsbedingungen dieses Forums vereinbar
ist, jedenfalls konnte ich nichts finden, was dagegen spräche.
http://87.106.84.105/avr-gcc_4.5.0_lto-support_2010-04-25.zip
Anwender, die ein installiertes WinAVR auf dem Rechner haben, können
dessen Dateien einfach mit denen des Archivs überschreiben.
Sollte es doch Einwände geben, so kann dieser Beitrag ja einfach von
einem Moderator gelöscht werden...
viele Grüße,
Lars
hmmm...
Bei mir fliegt das mit eineim internal compiler error raus noch bevor er
mit dem Erstellen der .i-Datei fertig ist. Allerdings nicht bei allen
Dateien...
Johann L. schrieb:> hmmm...>> Bei mir fliegt das mit eineim internal compiler error raus noch bevor er> mit dem Erstellen der .i-Datei fertig ist. Allerdings nicht bei allen> Dateien...
Ich habe ja dazu geschrieben, dass ich keine Gewähr dafür übernehmen
kann, ob es funktioniert bzw. ob dabei korrekter Code herauskommt.
Bei mir ist der Compiler jedoch noch nicht abgestürzt.
Eventuell gibt es ein Problem mit den verschiedenen Flags.
Ich habe im aktuellen Projekt:
Compiler:
Damit hatte ich bislang keine Probleme. Und ich habe bislang auch noch
keinen Grund entdeckt, wieso ich wieder eine ältere Version verwenden
sollte. Aber das kommt ja auch ein bisschen auf den jeweiligen
Einzelfall an und ob man bereit ist, herum zu experimentieren.
durchläuft. Wenn es bei dir auch abrauscht schliess ich mal
Build-Probleme aus und das er abschmiert weil ich ein anderes OS
verwende (W2K SP4).
Einsetzen wollte ich den 4.5.0 nicht, lediglich rumspielen und mal
schauen ob gcc 4.x inzwischen vielleicht besseren Code macht als 3.4.6
(in meinem aktuellen Prokejt ist 4.3.3 noch 3.6% größer als 3.4.6. Die
Größe wäre noch halbwegs erträglich, aber das Zeug ist auch langsamer
zudem).
>> durchläuft. Wenn es bei dir auch abrauscht schliess ich mal> Build-Probleme aus und das er abschmiert weil ich ein anderes OS> verwende (W2K SP4).
Sobald ich -mint8 übergebe ist Feierabend... (Segmentation fault)
Das reicht auch schon, damit Schluss ist:
1
avr-gcc-4.5.0 foo.c -mint8
Die "-m"-Flags sind sowieso problematisch, diese wirken sich scheinbar
unmittelbar auf die AVR-Assembler-Erzeugung aus. "-mcall-prologues" ist
das Einzige, was ich so übergebe.
Da ich dieses Flag, also -mint8, noch nie genutzt habe, ist mir das
Problem noch gar nicht aufgefallen.
Generell hat sich aber im Vergleich zu avr-gcc-4.3.3 die Schnelligkeit
des Codes erhöht, empfinde ich jedenfalls subjektiv so, wenn ich mir den
Assembler anschaue. Es wird zwar manchmal etwas größer, aber durch LTO
gleicht sich das bei mir wieder mehr als aus.
Ich nutze übrigens Windows XP Professional 32 Bit. Alles was neuer ist,
kommt mir nicht auf den Mac...
Vorsicht, Bugs mit -mint8 bitte möglichst nur zusammen mit einem
Patch berichten. Diese Option steht eigentlich schon lange auf der
Abschussliste, sodass ein nicht aufgelöster Bugreport schnell zum
Anlass genommen werden könnte, sie ganz zu eliminieren. (Dann ist
der Bug nämlich auch repariert...)
Jörg Wunsch schrieb:> Vorsicht, Bugs mit -mint8 bitte möglichst nur zusammen mit einem> Patch berichten.
Und wozu das? Patches werden eh nicht akzeptiert...
> Diese Option steht eigentlich schon lange auf der> Abschussliste, [...]
Ok, noch einen Grund nicht den 4-er zu verwenden...
Johann L. schrieb:> Patches werden eh nicht akzeptiert...
Stimmt nicht, allerdings ist das Patch-Handling, hmm, naja, suboptimal.
Man muss den ganzen Kram zwingend in eine Mailingliste posten, obwohl
das Zeug dort eigentlich nur durchrauscht. Das ist aber die Eintritts-
karte dafür, dass man anschließend jemanden nerven kann, damit man den
Patch auch eingepflegt bekommt... BTDT.
In diesem Fall hier ist es aber möglicherweise einfacher. Wenn der
Bug wirklich nur mit -mint8 zusammen hängt, dann ist es rein AVR-
spezifisch, sodass man nur einen der AVR-GCC maintainer (also letztlich
Anatoly Sokolov) davon überzeugen muss, der darf ihn dann selbst
committen. Ich gehe mal davon aus, dass der Patch auch nur so wenig
umfangreich ist, dass man dafür noch nicht den ganzen Zirkus mit dem
Copyright-Papierkram extra machen muss. (Hast du denn jemals eine
Antwort von der FSF bekommen, Johann?)
> Ok, noch einen Grund nicht den 4-er zu verwenden...
Vogel-Strauß-Prinzip?
Martin e. C. schrieb:
> Ich habe es probiert und kein Problem gehabt!
einwandfrei läuft doch nicht ganz!
wenn man als MCU ein Xmega eingibt dann ist FINITO!
Output Meldung:
c:\programme\winavr-20100110\bin\../lib/gcc/avr/4.5.0/../../../../avr/in
clude/avr/io.h:404:6: warning: #warning "device type not defined"
test2.c: In function 'TCE0_OVF_vect':
test2.c:39:3: error: 'TCNT0' undeclared (first use in this function)
test2.c:39:3: note: each undeclared identifier is reported only once for
each function it appears in
test2.c:41:20: error: 'PINF' undeclared (first use in this function)
und
.
.
.
.
Martin e. C. schrieb:> Martin e. C. schrieb:>> Ich habe es probiert und kein Problem gehabt!>> einwandfrei läuft doch nicht ganz!>> wenn man als MCU ein Xmega eingibt dann ist FINITO!
Das sieht mir aber mehr danach aus, dass kein passendes Headerfile für
den Controller vorhanden ist.
Der Compiler selbst ist dabei ja, im Gegensatz zu -mint8, nicht
abgestürzt.
Lars R. schrieb:
> Das sieht mir aber mehr danach aus, dass kein passendes Headerfile für> den Controller vorhanden ist.
doch es gibt oder es gabt, mit dem 4.3.3 war auf alle Fälle ganz ok!
vielleicht das mit dem:
> Anwender, die ein installiertes WinAVR auf dem Rechner haben, können> dessen Dateien einfach mit denen des Archivs überschreiben.
ist nicht ganz 100% ok (vermute ich).
Hallo,
ich habe den avr-gcc unter Linux ganz normal übersetzen können, aber die
avr-libc liess sich damit nicht bauen. Also habe ich die Versuche
erstmal wieder eingestellt.
Gruß
Olaf
Martin e. C. schrieb:> wenn man als MCU ein Xmega eingibt dann ist FINITO!
Weil die Xmega-Patches (aus Gründen, auf die ich hier nicht eingehen
mag) nach wie vor noch nicht im GCC-Tree sind. Die muss man manuell
drauf patchen.
Jörg Wunsch schrieb:
> Weil die Xmega-Patches (aus Gründen, auf die ich hier nicht eingehen> mag) nach wie vor noch nicht im GCC-Tree sind. Die muss man manuell> drauf patchen.
ahaa... alles klar!
unter Windows ist bestimmt nicht ganz eifach oder?
Martin e. C. schrieb:> unter Windows ist bestimmt nicht ganz eifach oder?
Das Patchen? Das macht das Kommando "patch", das muss man einfach
nur haben.
Problematischer dürfte es sein, Patches zu finden, die bereits sauber
auf einen GCC 4.5 portiert worden sind. U. U. leidest du daran, dass
diverse kleinere oder größere Änderungen den Patch nicht mehr 1:1
einpflegbar machen. Dann ist Handarbeit angesagt, und das ist
letztliche Erics (und die seiner Kollegen) Arbeit beim Herausbringen
eines neuen WinAVR (oder was auch immer dessen Nachfolger wird).
Jörg Wunsch schrieb:> Hast du denn jemals eine Antwort von der FSF bekommen, Johann?
Ich hatte noch ein paarmal nachgefragt und nochmal Adresse ect.
geschickt um sicher zu gehen, daß alles richtig übermittelt wurde.
Ausser einer Absichtserklärung, mir die Unterlagen zukommen zu lassen,
ist nichts geschehen.
Irgendwie hat alles einen ziemlich bocklosen Eindruck gemacht, und ich
bin auch nicht derjenige, der andere abnervt oder anbettelt, um irgendwo
beitragen zu dürfen...
In der Compiler-Bild gab's neulich einen Beitrag, der sich reger
Beteiligung erfreute.
http://gcc.gnu.org/ml/gcc/2010-04/msg00570.html
Offenbar bin ich nicht der einzige, der beim Versuch, die Hürden zu
überwinden, irgendwann frustriert aufgegeben hat.
Jörg Wunsch schrieb:>> Problematischer dürfte es sein, Patches zu finden, die bereits sauber> auf einen GCC 4.5 portiert worden sind. U. U. leidest du daran, dass> diverse kleinere oder größere Änderungen den Patch nicht mehr 1:1> einpflegbar machen. Dann ist Handarbeit angesagt, und das ist> letztliche Erics (und die seiner Kollegen) Arbeit beim Herausbringen> eines neuen WinAVR (oder was auch immer dessen Nachfolger wird).
Wie ich gesehen habe hat Eric inzwischen ein Assignment, aber dennoch
gibt es für WinAVR eine riesige Patch-Liste, die auch Patches für gcc
beinhaltet. Gibt es einen Grund, diese nicht in gcc einzupflegen? Es ist
ja eine tierische Arbeit, immer alles Zeug zurück- oder vor zu portieren
bzw. die Patches auf jedes neues Release anzupassen.
Ausserdem wird es so viel schwerer, den Überblick zu behalten, und kein
avr-Maintainer wird bereitwillig gcc-Patches ins FSF-Repository nehmen,
weil das zusätzlichen Aufwand für die Nachpflege der "Privat"-Patches
für die nächste Release bedeuten würde.
Johann L. schrieb:>> Hast du denn jemals eine Antwort von der FSF bekommen, Johann?>> Ich hatte noch ein paarmal nachgefragt und nochmal Adresse ect.> geschickt um sicher zu gehen, daß alles richtig übermittelt wurde.> Ausser einer Absichtserklärung, mir die Unterlagen zukommen zu lassen,> ist nichts geschehen.
Schei...
Bei mir hatte das seinerzeit relativ problemlos geklappt, auch
wenn ich das nach wie vor als "Luftnummer" betrachte, insbesondere
natürlich angesichts der Nichtübertragbarkeit der Urheberschaft
gemäß deutschem Urheberrecht:
http://de.wikipedia.org/wiki/Deutsches_Urheberrecht#.C3.9Cbertragbarkeit_des_Urheberrechts
(die bei den Amis regelmäßig auf komplettes Unverständnis stößt,
da deren Copyright die Urheberschaft mit den Nutzungsrechten daran
vermischt).
> Irgendwie hat alles einen ziemlich bocklosen Eindruck gemacht, und ich> bin auch nicht derjenige, der andere abnervt oder anbettelt, um irgendwo> beitragen zu dürfen...
Naja, wenn du Bock hast, überhaupt einen deiner Beiträge (die ich
persönlich für wertvoll finde) durchzuboxen, dann würde ich die
Sache einfach eskalieren lassen: einreichen, nachtreten, und bei
der Frage nach dem copyright assignment stets betonen, dass du es
eingereicht hast, aber die FSF offenbar nicht interessiert ist.
> In der Compiler-Bild gab's neulich einen Beitrag, der sich reger> Beteiligung erfreute.> http://gcc.gnu.org/ml/gcc/2010-04/msg00570.html
Manuel ist mir schon mehr als einmal als sehr hilfreiche Person
aufgefallen. Wenn ich mich nicht täusche, hat er seinerzeit den
0b-Patch auch mit voran getrieben.
> Offenbar bin ich nicht der einzige, der beim Versuch, die Hürden zu> überwinden, irgendwann frustriert aufgegeben hat.
Wobei andere offensichtlich noch schlimmere Hürden zu nehmen haben:
die Amis müssen sich noch einen Disclaimer ihres Brötchengebers
einholen. Davon sind wir zum Glück verschont. Auf Dinge, die du
in deiner Freizeit machst hat (sofern du damit nicht gegen deine
dienstlichen Geheimhaltungspflichten verstößt, d. h. keine Dienst-
geheimnisse preisgibst) dein Brötchengeber hier keinerlei Anspruch.
Ein anderer Aspekt, in dem sich das deutsche Urheberrecht vom
US-Copyright unterscheidet.
> Wie ich gesehen habe hat Eric inzwischen ein Assignment, aber dennoch> gibt es für WinAVR eine riesige Patch-Liste, die auch Patches für gcc> beinhaltet. Gibt es einen Grund, diese nicht in gcc einzupflegen?
Ich denke, dass gerade bei den Xmegas der Grund einfach Zeitmangel
ist, das so weit aufzubereiten, dass Anatoly es einpflegen kann.
Die meisten anderen Patches, die GCC-seitig bei WinAVR herumlungern,
sind ja Sachen, die im SVN bereits korrigiert sind, die er aber auf
die jeweils bei WinAVR gelieferte ältere Compilerversion rückportiert
haben möchte.
Jörg Wunsch schrieb:> Auf Dinge, die du> in deiner Freizeit machst hat (sofern du damit nicht gegen deine> dienstlichen Geheimhaltungspflichten verstößt, d. h. keine Dienst-> geheimnisse preisgibst) dein Brötchengeber hier keinerlei Anspruch.
Das könnte sich aber mit der jüngsten BGH Entscheidung zur Zulässigkeit
von Softwarepatenten und dem bestehenden Gesetz über
Arbeitnehmererfindungen (§18 und §19) ändern.
Stefan B. schrieb:> Das könnte sich aber mit der jüngsten BGH Entscheidung zur Zulässigkeit> von Softwarepatenten und dem bestehenden Gesetz über> Arbeitnehmererfindungen (§18 und §19) ändern.
Jein. Die möglichen Grenzen für Softwarepatente sind relativ eng,
die Software muss ein technisches Problem lösen, das vergleichbar
anderweitig mit "herkömmlicher Technik" gelöst worden wäre. Der
Wikipedia-Artikel zu Softwarepatenten geht recht ausführlich darauf
ein. Es ist nicht einfach jedes x-beliebige Stück Software
patentierbar.
Außerdem müsste im Zweifelsfalle der Brötchengeber hier als Kläger
auftreten, dafür muss er dann den Nachweis erbringen, dass die
strittige Softwarelösung patentreif gewesen wäre, also einerseits
die rechtlichen Patentvoraussetzungen erfüllt, andererseits die
Voraussetzung, dass bis dato keine vergleichbare Lösung veröffentlicht
worden war. Gerade letzteres dürfte für das Themengebiet, das wir
hier im Blick haben (Compilertechnologie) außerordentlich schwierig
werden.
Mir als Rechtslaien fällt es ganz schwer die Auswirkungen verbindlich
abzuschätzen.
Ich zähle in diesem Fall in guter paranoider Manier 1+1 zusammen und
verpasse mir ein Eselsohr "aufpassen", weil alte Regeln (Freizeit =>
keinerlei Anspruch...) eventuell ab jetzt nicht mehr gelten. Ob das
berechtigt ist, wird die Zeit zeigen.
Der "Ami" bannt durch den Disclaimer grundsätzlich die Gefahr, dass ihn
sein AG deswegen vor Gericht zerrt. Unsere Schonung ist vielleicht nur
ein Scheinvorteil.
Was haben denn Arbeitnehmererfindungen mit den Hobby-Ergebnissen der
Freizeit zu tun, die weder innerhalb der Arbeitszeit noch unter Nutzung
irgendwelcher Arbeitgeber-Infrastruktur zustandegekommen sind und auch
keine Betriebsgeheimnisse berühren?