Hallo!
Im avr-gcc Compiler hat sich in den letzten Jahren viel verändert.
Programme, welche unter WinAVR-20100110 erstellt wurden, lassen sich
unter der aktuellen Toolchain nicht ohne Umbauten im Code kompilieren.
Für kleinere Änderungen und Erweiterungen im Code von solchen
Programmen, benutzte ich bislang weiterhin den WinAVR-20100110.
Nun möchte ich auf Linux umsteigen (Linux-Mint17.1). Wenn ich die
Toolchain über die Linux-Paketverwaltung installiere, dann erhalte ich
avr-gcc 4.8.2, binutils 2.23.1, avr-libc 1.8.0.
Ich hätte aber gern die Pakete, welche in WinAVR-20100110 benutzt werden
(avr-gcc 4.3.3, binutils 2.19.1, avr-libc 1.6.8).
Bei der Suche fand ich unter
http://www.mikrocontroller.net/articles/AVR_und_Linux den Verweis auf
http://www.wrightflyer.co.uk/avr-gcc/ und dort die entsprechende Version
(avr-gcc-4.3.3-avrfreaks-23-feb-2010-special.deb).
Der Installationsversuch brachte folgende Fehlermeldung:
dpkg: Fehler beim Bearbeiten des Archivs
/tmp/avr-gcc-4.3.3-avrfreaks-23-feb-2010-special.deb (--install):
Parsen der Datei »/var/lib/dpkg/tmp.ci/control«, nahe Zeile 10 Paket
»avr-gcc-4.3.3-avrfreaks-23-feb-2010-special«:
Leerzeile im Wert des Feldnamen »Description«
Leider bin ich noch ein Linux-DaU und kann mit der Fehlermeldung nichts
anfangen.
Schon jetzt vielen Dank für die Hilfestellung.
Nero schrieb:> Leider bin ich noch ein Linux-DaU und kann mit der Fehlermeldung nichts> anfangen.
Dann hast jetzt zwei Baustellen.
1. Sonderversion des avr-gcc (was normalerweise einen ziemlichen
Rattenschwanz an Abhaengigkeiten nach sich zieht)
2. Sondersyntax in Deinem Code
Als erste musst Du also entscheiden, welche zuerst fertig werden soll,
beide gleichzeitig geht nicht. Finde heraus, was einfacher wird.
ICH als Linuxuser mit ca. 15 Jahren Erfahrung wuerde ueber 1. gar nicht
weiter nachdenken.
wendelsberg
Nero schrieb:> Ich hätte aber gern die Pakete, welche in WinAVR-20100110 benutzt werden> (avr-gcc 4.3.3, binutils 2.19.1, avr-libc 1.6.8).
Warum willst du derartig veraltetete, teils recht buggige und schlechte
Tools benutzen, statt lieber deinen Code aufzuräumen?
Aber es steht dir völlig frei, dir deine eigene x-beliebige Version
des Compilers zu bauen und irgendwo bei dir zu installieren. Die
Quellen der damaligen Tools und auch Eric Weddingtons Patches findest
du meines Wissens nach wie vor alle im Netz, und das bisschen Bauen
ist unter Linux nun auch keine Raketenwissenschaft. Benutze aber
sinnvollerweise einen customized --prefix, damit sie sich mit den
moderneren Tools nicht ins Gehege kommen. Die Auswahl, welche Toolchain
du benutzt, machst du dann, indem du ${PREFIX}/bin deinem PATH
voranstellst oder nicht.
Welche Codestellen übersetzen denn unter aktuellem gcc nicht mehr?
Wäre mir neu dass man da die Abwärtskompatiblität über Board schmeisst.
Selbst uralte legacy-Header werden doch noch mit ausgeliefert (ok, das
ist avr-libc, aber auch ein Teil der Toolchain).
Außer natürlich du hast irgendwelche fiesen Hacks drin, aber dann
solltest du eh drüber nachdenken, diese rauszuschmeissen.
Karlo schrieb:> Welche Codestellen übersetzen denn unter aktuellem gcc nicht mehr?
„prog_char“ zum Bleistift. Das war mal ein Designfehler der avr-libc,
der nur lange Zeit vom GCC toleriert worden ist.
Kann man aber völlig simpel durch ein paar #defines lösen, wenn man
den Code nicht umschreiben will, denn „prog_char“ war am Ende (aus
Sicht des Compilers) nie ein anderer Typ als „char“. Das „prog_“
hatte lediglich einen dokumentierenden Effekt, um das tatsächliche
Handling musste man sich selbst kümmern. Kann man auch durch
Definieren von _PROG_TYPES_COMPAT_ aus dem Headerfile bekommen,
allerdings ergibt das dann eine deprecation warning.
Vielen Dank für die Antworten!
@wendelsberg
>Als erste musst Du also entscheiden....
Wie soll ich das machen?
Da ich Linux-Anfänger bin, habe ich doch überhaupt keine Möglichkeit den
Aufwand abzuschätzen. Immerhin weiss ich gar nicht, was da zu tun ist
und wie das geht. So kompliziert hatte ich mir aber den Austausch von 3
Paketen nicht vorgestellt.
Immerhin ist es unter Windows auch nicht kompliziert eine ältere
WinAVR-Version zu installieren.
Da ich aber keine Ahnung habe, kann ich nur deiner 15 jährigen Erfahrung
vertrauen.
@Jörg Wunsch
>Warum willst du derartig veraltetete, teils recht buggige und schlechte>Tools benutzen
So buggy und schlecht fand ich den gar nicht. Zumindest hatte ich nie
Probleme damit. Mag natürlich sein, dass ich bislang die Bugs nicht
entdeckt habe.
Ich hatte sogar manchmal noch die Version aus 2006 benutzt, da hier ein
kleinerer und schnellerer Maschinencode generiert wird. Für den
Generationswechsel 2006 -> 2010 sieht man also, dass neuer nicht
unbedingt auch besser bedeuten muss.
>...statt lieber deinen Code aufzuräumen?
Um einige geringfügige Änderungen in einen Code einzubringen, der seit
Jahren problemlos läuft, schien mir das (nur weil die neue
Compilerversion herumzickt) einfach nicht gerechtfertigt (never change a
running system).
Ich will ja zugeben, dass die Umbauten zur Beseitigung von
Fehlermeldungen nicht so gross sind (z. B. PROGMEM char als const zu
erklären). Zusätzlich bekomme ich aber jetzt einen ganzen Sack voll
Warnmeldungen und dass nervt. Insbesondere habe ich den Eindruck, dass
der gcc 4.3.3 bei einem Fehler auch wirklich zeitnah abgebrochen hat.
Die neue Version schreibt nach dem Fehler lustig weiter Warnungen in das
Ausgabefenster, so dass ich dann eine etwaige Fehlermeldung regelrecht
suchen muss.
Ich will es einmal so ausdrücken, dass mir die alte Version
benutzerfreundlicher erscheint.
>Die Quellen der damaligen Tools und auch Eric Weddingtons Patches findest>du meines Wissens nach wie vor alle im Netz, und das bisschen Bauen>ist unter Linux nun auch keine Raketenwissenschaft.
Mein Problem ist doch nicht die Quellen zu finden! Die habe ich doch
schon gefunden!
Die von mir verlinkte avr-gcc-4.3.3-avrfreaks-23-feb-2010-special.deb
ist lt. Beschreibung von avrfreaks doch schon die Linux-Variante von
WinAVR-20100110 incl. der Patches von Eric Weddington. Ich weiss
wirklich nicht, welchen Vorteil ich davon habe, mich in den Bau einer
Toolchain einzuarbeiten. Die liegt mir doch schon fertig vor.
Mein Problem ist, dass sich das nicht installieren lässt.
@ Karlo
>Außer natürlich du hast irgendwelche fiesen Hacks drin...
Nein, fiese Hacks sind da nicht drin und die Umbauten vermutlich nicht
gross. Wie vorstehend geschrieben ist es mehr die
Benutzerfreundlichkeit, die ich an der älteren Version geschätzt habe.
Und wenn die AVR-Typen, die ich benutze, von der 4.3.3 Version abgedeckt
werden, sehe ich erst einmal nicht die Veranlassung etwas anderes zu
nehmen.
Es ist wie mit den Betriebssystemen eines amerikanischen
Grossunternehmens (oder auch dem Hersteller meines Staubsaugers). Nur
weil die ein neues Modell herausbringen, sehe ich mich überhaupt nicht
veranlasst, so etwas einzusetzen (insbesondere dann nicht, wenn es auch
noch Arbeit und/oder Geld kostet), solange ich mit der vorhandenen
Version zufrieden bin.
Nero schrieb:> der seit> Jahren problemlos läuft
Naja, nur weil etwas "laeuft", heisst das ja nicht, das es auch
"richtig" laeuft. Der Farbdrucker druckt, zwar nur schwarz-weiss, aber
er druckt...
Nero schrieb:> Ich hatte sogar manchmal noch die Version aus 2006 benutzt, da hier ein> kleinerer und schnellerer Maschinencode generiert wird. Für den> Generationswechsel 2006 -> 2010 sieht man also, dass neuer nicht> unbedingt auch besser bedeuten muss.
Da muss man dann ja erstmal definieren was ueberhaupt "besser" ist. Es
wurden auch mal Betriebssysteme in Asm geschrieben. Ob diese (oder deren
Code) jetzt aber wirklich "besser" sind/waren, als die heutigen, sei mal
dahin gestellt. Es gibt auch Menschen, die finden es "besser" moeglichst
spritsparend zu fahren, andere finden es "besser" schnell zu fahren...
Das kann man beliebig fortfuehren.
Nur weil der Maschinencode in aelteren versionen "kleiner und schneller"
war, heisst das nicht zwangslaeufig, das er auch "besser" war.
Ein Golf 1 ist auch "besser", wenn es z.B. um das Gewicht geht, da er
leichter ist. Deswegen ist mir ein Golf 4 und neuer trotzdem lieber,
weil er mehr Sicherheit bietet, also in diesen Punkten deutlich "besser"
ist...
Also:
War der generierte Code wirklich besser, nur weil er "kleiner und
schneller" war?
Nero schrieb:> der 4.3.3 Version abgedeckt> werden, sehe ich erst einmal nicht die Veranlassung etwas anderes zu> nehmen.
Wie waere es denn mit diesen Gruenden:
- gefixte Bugs
- "bessere"/andere Optimierung
- striktere Einhaltung des Standards
Ansonsten ist deine Argumentation:
Das haben wir schon immer so gemacht,...
Nero schrieb:> Zusätzlich bekomme ich aber jetzt einen ganzen Sack voll> Warnmeldungen und dass nervt. Insbesondere habe ich den Eindruck, dass> der gcc 4.3.3 bei einem Fehler auch wirklich zeitnah abgebrochen hat.> Die neue Version schreibt nach dem Fehler lustig weiter Warnungen in das> Ausgabefenster, so dass ich dann eine etwaige Fehlermeldung regelrecht> suchen muss.
Alle weiteren Fehler sind folge Fehler, bassierend auf dem ersten
Fehler. Alles was du "suchen" musst, ist der erste Fehler.
Nero schrieb:> Ich will es einmal so ausdrücken, dass mir die alte Version> benutzerfreundlicher erscheint.
Du willst also eine Toolchain, die dir nicht auf den Zeiger geht, und
gefunden Fehler gefaelligst zu ignorieren hat, verstehe...
Es gibt gute Gruende, weshalb es immer wieder neue Versionen und Patches
eines Compilers erscheinen, und einer dieser Gruende ist mit Sicherheit
nicht das den Compilerbauern langweilig ist...
Kaj G. schrieb:>Nur weil der Maschinencode in aelteren versionen "kleiner und schneller">war, heisst das nicht zwangslaeufig, das er auch "besser" war.> Es gibt gute Gruende, weshalb es immer wieder neue Versionen und Patches> eines Compilers erscheinen
Dass es Gründe gibt sei unbestritten. Ob diese Gründe immer
deckungsgleich mit den Interessen des Anwenders sein müssen, ist damit
nicht vorausgesetzt.
Bei der Compilergeneration 2006 zu 2007 - 2010 war es einfach so, dass
neue Typen (Xmegas) hinzugekommen sind, die das erforderlich gemacht
haben. Sicherlich wichtig für Anwender, die Xmegas einsetzen wollten und
ein No-Go für Anwender die zeitkritische Anwendungen auf AVR haben, oder
bei Code-Erweiterungen, wenn der Flashbereich schon mit der 2006er
Version gut gefüllt war.
Mit dieser Meinung stehe ich übrigens nicht allein dar:
Beitrag "Codesize WinAVR 20060421 vs WinAVR-20090313"http://forum.mikrokopter.de/topic-post124526.htmlhttp://forum.mikrokopter.de/topic-post198537.html#post198537
Mir ist durchaus bekannt, dass es Menschen gibt, die immer das neueste
haben müssen, auch wenn damit kein Vorteil verbunden ist, genau so, wie
es Menschen gibt, die mit funktionierenden Dingen zufrieden sind und
erst einmal abwarten, ob sich etwas Neues auch wirklich bewährt und
einen Vorteil bringt.
Glücklicherweise wird ja niemand gezwungen, ins eine oder andere Lager
zu wechseln. Ich habe also absolut nichts dagegen, wenn du dir 4x im
Jahr einen neuen Staubsauger kaufen möchtest!
Im überigen ist mir der Sinn deines Beitrages unklar geblieben?
Ich habe dich (oder auch andere) nicht dazu aufgefordert, neue Dinge
nicht zu verwenden. Ich habe lediglich auf die Frage geantwortet und
eine Begründung aus meiner Sicht geliefert, warum ich die 2010er
Toolchain haben möchte.
Und nochmal zur Erinnerung:
Die Eingangsfrage war, wie man die 2010er Toolchain in Linux
installieren kann?
Das ist eine rein techniche Frage, die du offensichtlich nicht
beantworten kannst und zu deren Lösung du nicht beigetragen hast!
Also tu mir bitte einen Gefallen und mach aus meiner technischen Frage
keine weltanschauliche Diskussion!
Nero schrieb:> eine Begründung aus meiner Sicht geliefert, warum ich die 2010er> Toolchain haben möchte.
Weil Du zu faul bist, die vielleicht 15-20 Aenderungen in Deinen Code
einzubauen oder eventuell sogar weitgehend automatisch dort
hineinzueditieren.
Nero schrieb:> Die Eingangsfrage war, wie man die 2010er Toolchain in Linux> installieren kann?
Indem man ein entsprechend altes Linux als Unterbau benutzt, sozusagen
einen alten Golf besorgen, weil dort die Bierkisten schoener in die
Klappe passten.
Wie Du das anstellst, recherchierst Du aber bitte selbst, kaum jemand
sonst hat dafuer Bedarf.
Und ich bleibe dabei, Du bist auf dem Holzweg.
wendelsberg
Nero schrieb:> Ich hätte aber gern die Pakete, welche in WinAVR-20100110 benutzt werden> (avr-gcc 4.3.3, binutils 2.19.1, avr-libc 1.6.8).Nero schrieb:> So kompliziert hatte ich mir aber den Austausch von 3> Paketen nicht vorgestellt.
Hallo Nero,
die drei Pakete haben weitere Abhängigkeiten:
$> aptitude show gcc-avr
Depends: libc6 (>= 2.11), libgmp10, libmpc2, libmpfr4 (>= 3.1.0), zlib1g
(>= 1:1.1.4), binutils-avr (>= 2.18-4)
Suggests: task-c-devel, gcc-doc (>= 4:4.0.2-1), gcc-4.2, avr-libc (>=
1:1.6.2-2)
Conflicts: avr-libc (<= 1:1.7.1-2), avr-libc (<= 1:1.7.1-2), gcc-avr
$> aptitude show binutils
Depends: libc6 (>= 2.11), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.6),
zlib1g (>= 1:1.2.0)
Suggests: binutils-doc (>= 2.22-8+deb7u2)
Conflicts: binutils-gold (< 2.20.51.20100415), binutils-gold (<
2.20.51.20100415), elf-binutils, elf-binutils, gas, gas, modutils (<
2.4.19-1), modutils (< 2.4.19-1), binutils
$> aptitude show avr-libc
Depends: gcc-avr (>= 1:4.7-1), binutils-avr (>= 2.20.1-2)
und diese weiteren benötigten Pakete haben auch wieder Abhängigkeiten.
Daher ist es besonders bei großen Versionssprüngen aufwändig von den
Versionen der Pakete in der Distribution abzuweichen.
Das ist auch einer der Gründe warum ein neues Release einer
Linux-Distribution Zeit braucht. Alle Pakete müssen zueinander
kompatibel sein.
In speziellen Fällen ist es aber durchaus möglich unterschiedliche
Versionen nebeneinander zu installieren.
Alexander S. schrieb:> In speziellen Fällen ist es aber durchaus möglich unterschiedliche> Versionen nebeneinander zu installieren.
Natuerlich. Nur ist das nichts fuer Anfaenger.
wendelsberg
Mit den dynamisch gelinkten *.deb Paketen wirst du kein Glück haben, zu
groß ist die Abhängigkeitshölle. Wenn du statisch gelinkte Pakete
findest, am besten noch im tgz Format, die du dann in einen extra Ordner
packst und einen Link auf die Executables z.B. nach /usr/local/bin
legst, bist du fertig. Ich weiß allerdings nicht, ob statisch gelinkte
Packete existieren.
Die Alternative ist es, die Packete selber zu compilieren. Läuft aber
evtl. auf die gleiche Abhängigkeitsproblematik heraus.
Ich bin Linux User seit 20 Jahren, würde nie im Traum dran denken, auf
Windows zurück zu wechseln (reicht mir, dass ich im Job immer noch mit
arbeiten muss), aber die Problematik, dass man nicht einfach alte
Programmversionen zum Laufen bringt, ist ein echter Nachteil. Uralte
Executables in Windows laufen meist problemlos (außer bei Problemen mit
neuen Treibern); in Linux dagegen geht das so nicht. Dazu sind die
Abhängigkeiten der Programme von endlos unterschiedlichen Bibliotheken
und deren Abhängigkeiten, ... einfach zu groß - und die Bibliotheken
ändern sich einfach zu schnell. Die ganze Softwareumgebung ist viel mehr
im Fluss.
Ich will nicht sagen, du kannst die alte Version nicht zum Laufen
bringen, aber es ist sicher nichts für einen neuen Linux-Umsteiger.
Evtl. ist es wirklich einfacher, eine alte Linuxversion in einer VB zu
installieren wenn du dein Programm nicht ändern magst.
Just my 2c
Gerhard
Nero schrieb:> Ich hatte sogar manchmal noch die Version aus 2006 benutzt, da hier ein> kleinerer und schnellerer Maschinencode generiert wird. Für den> Generationswechsel 2006 -> 2010 sieht man also, dass neuer nicht> unbedingt auch besser bedeuten muss.
Mit GCC 4.7 (und Johann Lays Mitarbeit) hat sich da aber ein
Riesenschritt nach vorn getan. Das allein ist eigentlich Grund
genug, neuere Versionen zu benutzen.
>>...statt lieber deinen Code aufzuräumen?>> Um einige geringfügige Änderungen in einen Code einzubringen, der seit> Jahren problemlos läuft, schien mir das (nur weil die neue> Compilerversion herumzickt) einfach nicht gerechtfertigt (never change a> running system).
Das ist natürlich richtig. Wenn es rein nur um die Wartung
existierenden Codes geht (ohne ihn nennenswert umzustellen oder
zu erweitern), ist es sinnvoll, den damaligen Compiler zu nehmen.
> Zusätzlich bekomme ich aber jetzt einen ganzen Sack voll> Warnmeldungen und dass nervt.
Du solltest dir dabei natürlich die Warnungen sehr genau ansehen:
der Grund für die Warnungen war ja auch damals schon vorhanden, der
alte GCC hat das nur nicht herausgefunden. Es ist also gut möglich,
dass da noch latente Bugs in deinem Code sind, die nur bislang nicht
getriggert worden sind.
> Die von mir verlinkte avr-gcc-4.3.3-avrfreaks-23-feb-2010-special.deb> ist lt. Beschreibung von avrfreaks doch schon die Linux-Variante von> WinAVR-20100110 incl. der Patches von Eric Weddington. Ich weiss> wirklich nicht, welchen Vorteil ich davon habe, mich in den Bau einer> Toolchain einzuarbeiten.
Dass eben die von dir gefundene Version einfach mal in deiner Umgebung
nicht läuft. Du müsstest dazu ein gleichermaßen altes Debian-Linux
aufsetzen, um sie direkt benutzen zu können. (*)
Das Aufdröseln der Abhängigkeiten der alten Version wird sich als
drastisch schwieriger gestalten, als den alten Compiler unter einem
aktuellen Linux einfach selbst neu zu compilieren. Das ist nämlich
in der Regel nicht viel mehr als das typische
1
./configure --target=avr --prefix=$MYPREFIX; make ; make install
OK, beim GCC ist es
1
mkdir build ; cd build
2
../configure --target=avr --prefix=$MYPREFIX; make ; make install
3
cd ..
und bei der avr-libc
1
./configure --build=`./config.guess` --host=avr --prefix=$MYPREFIX; make ; make install
(Das mit dem configure würde er dir aber auch bei einem Versuch,
einfach ./configure aufzurufen, ausspucken.)
Neuere GCCs sind bezüglich der Abhängigkeiten von Bibliotheken etwas
anspruchsvoller (GMP, MPFR, MPC), aber der alte 4.3er war da meiner
Erinnerung nach noch recht genügsam.
Ein bisschen lästig ist es, dass die typischen Linux-Distros für
irgendwelche installierten Bibliotheken die Headerfiles nicht
freiwillig mit installieren; diese muss man ggf. über die jeweiligen
»-dev«-Pakete nachinstallieren (also »libgmp-dev« für die Bibliothek
»libgmp« etc.), damit sie beim Compilieren gefunden werden.
(*) Was natürlich durchaus eine potenzielle Alternative sein kann:
Installier dir eine VirtualBox und dahinein ein entsprechend altes
System, und bau den Salat dann darin.
Gerhard Z. schrieb:> Die ganze Softwareumgebung ist viel mehr im Fluss.
Naja, es würde genügen, wenn man die alten Bibliotheksversionen
irgendwo „abseits“ in einem compat-Verzeichnis nachinstallieren
könnte, damit sie von den executables noch gefunden werden.
Aber die Versions-Inflationitis bei manchen Bibliotheken geht wirklich
auf keine Kuhhaut. Muss das wirklich jedesmal eine neue major version
number sein, d. h. haben sich existierende ABIs inkompatibel geändert?
Nur wegen hinzugefügter weiterer Funktionen muss man eigentlich die
major version nicht hochzählen, denn das ist ja völlig
rückwärtskompatibel.
Open/extract the .deb archive with linux archiver
Copy the files+dirs from the archives /usr/local/ to the pc's
/usr/local/
That would be the whole avr directory.
But you might run into dependancies/shared libs probs.
(it was built under ubunu 10.0.4 32-bit).
i'd say you need to install mpfr/gmp and libusb (and hope)
/Bingo
wendelsberg schrieb:
>Weil Du zu faul bist, die vielleicht 15-20 Aenderungen in Deinen Code>einzubauen oder eventuell sogar weitgehend automatisch dort hineinzueditieren.
Das hat doch mit Faulheit nichts zu tun. Glaubst du etwa wirklich, ich
hätte die Änderungen zur Beseitigung der Fehlermeldungen nicht (schon
rein aus Interesse) einmal gemacht?
Wie sollte ich dann wissen, dass der neue Compiler jede Wenge
Warnmeldungen ausgibt, wenn er es überhaupt nicht übersetzt?
Nein, Faulheit ist das nicht, sondern gesunder Menschenverstand und die
Erfahrung, dass "never change a running system" kein hohler Spruch ist!
>Und ich bleibe dabei, Du bist auf dem Holzweg.
Mag ja sein, dass ich mit Linux auf dem Holzweg bin. Das wird sich noch
zeigen (habe noch nicht aufgegeben).
Mit der Benutzung der 2010er Toolchain für eine Bagatelländerung bei
einen vorhandenen Code,
- der mit dieser Toolchain erstellt wurde,
- der seinerzeit umfangreich und zeitaufwendig getestet wurde,
- der seine Feuerprobe durch jahrlangen Gebrauch in der Praxis unter
Beweis gestellt hat und
- mit dem der Anwender höchst zufrieden ist,
bin ich garantiert nicht auf dem Holzweg!!!
Ich bleibe dabei "never change a running system" und das gilt auch für
den Compiler! So gross ist mein Vertrauen in die Abwärtskompatibilität
nun auch wieder nicht. Habe wenig Lust mir unnötigen Ärger und Probleme
einzuhandeln.
Falls das, was ich machen möchte, mit Linux nicht funktioniert, dann
erkläre ich das Linux-Experiment für gescheitert und Windows kommt
wieder auf die Platte! Was nützen die zahlreichen Vorteile, die Linux
unbestritten hat, wenn die für mich wesentlichen Dinge nicht laufen?
Nero schrieb:> Falls das, was ich machen möchte, mit Linux nicht funktioniert
Warum setzt du dich nicht einfach mal auf den Hosenboden und
compilierst dir das bisschen Compiler? Die notwendigen Schritte
habe ich dir oben umrissen. Du wärst damit jetzt schon fertig.
Eine Alternative (VirtualBox, damalige alte Ubuntu-Version hinein,
Bingo hat dir ja auch noch geschrieben, welche es ist, dann dort das
.deb-Paket auspacken) habe ich dir auch genannt.
Aber machen musst du's schon selbst.
Für neuen Code jedoch würden wir dir allesamt abraten, die alte
Toolchain noch zu benutzen. Deine Anmerkungen waren da leider nicht
immer so eindeutig, ob du das nicht zumindest unterschwellig
beabsichtigst.
Nero schrieb:> Nein, Faulheit ist das nicht, sondern gesunder Menschenverstand und die> Erfahrung, dass "never change a running system" kein hohler Spruch ist!Nero schrieb:> Nun möchte ich auf Linux umsteigen
;)
Bleib mit deinen alten Projekten auf einem Windows-System (dual boot ist
ja nun kein Hexenwerk) , und alles wird gut.
Neue Projekte kannst du dann problemlos unter Linux anlegen.
Uralte toolchains, dazu noch in einer Version, die es nur unter Windows
gab, für aktuelle Projekte unter Linux zu nutzen, bringt nix ausser
Ärger.
Oliver
Oliver S. schrieb:> Uralte toolchains, dazu noch in einer Version, die es nur unter Windows> gab
Vermutlich könnte man den alten Kram sogar direkt mittels wine
starten.
Jörg Wunsch schrieb:
>...und compilierst dir das bisschen Compiler? Die notwendigen Schritte>habe ich dir oben umrissen.
Ja hast du - und vielen Dank dafür!
Leider reicht dieses "umreißen" für einen Linux-DaU nicht. Da würde ich
schon eher eine Art Kochbuch benötigen, dass damit anfängt, welche
Toolchain ich installieren müsste, um den Compiler zu compilieren? Habe
da absolut keinen Plan.
Zudem müsste ich vermutlich anstatt der .deb den Quellcode haben und den
müsste ich auch erst ergoogeln.
>VirtualBox, damalige alte Ubuntu-Version hinein... Bingo hat dir ja auch>noch geschrieben, welche es ist
auch dafür vielen Dank an Bingo!
Habe ich gemacht, die .deb konnte ich trotzdem nicht installieren.
Keinen Schimmer warum.
Oliver S. schrieb:
>Bleib mit deinen alten Projekten auf einem Windows-System (dual boot ist>ja nun kein Hexenwerk) und alles wird gut.
Das ist richtig. Zuvor war ich nur auf Win und da war prinzipiell auch
alles gut.
Wollte es eben mal mit Linux probieren, weil mir das ja als so tolles
System angepriesen wurde. Das ist Linux auch sicherlich, wenn man
Internet, Office und ein paar Standard-Programme betrachtet.
Bei mir reift nur einfach Ernüchterung und die Erkenntnis, dass man bei
etwas anderen Anwendungen ganz schön auf dem Schlauch steht, wenn man
nicht gerade ein Linux-Experte ist.
Natürlich ist Dual-boot kein Problem oder auch Windows in Virtualbox.
Das wäre doch aber der Beleg, dass an Windows sowieso kein Weg vorbei
führt und wenn sich das wirklich bestätigen sollte, müsste ich mich doch
fragen, wozu Linux und das hin und her booten gut sein soll? Ein
bisschen Internet, Office und ein paar Standard-Programme kann Windows
ja ebenfalls.
Jörg Wunsch schrieb:
>Vermutlich könnte man den alten Kram sogar direkt mittels wine starten.
Hab es gerade probiert und es läuft tatsächlich. Also prinzipiell eine
gute Idee!
Aber auch hier kommt die Ernüchterung im Gebrauch. Ein Compiliervorgang,
der unter Linux (mit neuem gcc) in ca. 3,5 sek erledigt ist, benötigt
unter Wine ca. 1 Minute.
Aber immerhin, bis jetzt der erste (bei mir funktionierende) Ansatz, der
ohne Windows auskommt!
Nero schrieb:> Bei mir reift nur einfach Ernüchterung und die Erkenntnis, dass man bei> etwas anderen Anwendungen
Du hast eine EXTREM andere Bedingung, die Du auf Biegen und Brechen
erfuellt haben willst, da liegt der Hase im Pfeffer.
wendelsberg
Nero schrieb:> Aber auch hier kommt die Ernüchterung im Gebrauch. Ein Compiliervorgang,> der unter Linux (mit neuem gcc) in ca. 3,5 sek erledigt ist, benötigt> unter Wine ca. 1 Minute.
Was soll da auch anderes herauskommen:
eine Linuxtoolchain, die auf Windows gefrickelt wurde, dann unter einem
simulierten Windows auf einem Linux laufen zu lassen, ist schon ziemlich
abwegig, um nicht zu sagen, pervers.
wendelsberg
wendelsberg schrieb:
>eine Linuxtoolchain, die auf Windows gefrickelt wurde, dann unter einem>simulierten Windows auf einem Linux laufen zu lassen, ist schon ziemlich>abwegig, um nicht zu sagen, pervers.
Nun - diese "Perversität" stammt nicht von mir sondern von Jörg Wunsch!
Auch wenn die "Perversität" etwas lahm ist, so bin ich dem Jörg doch
dankbar, dass er mich auch auf diese Möglichkeit aufmerksam gemacht hat.
wendelsberg schrieb:
>Du hast eine EXTREM andere Bedingung, die Du auf Biegen und Brechen>erfuellt haben willst,
Findest du das wirklich so? Es entwickelt sich für mich doch eher zu der
Frage nach Linux oder Windows.
Für das Compiler-Problem gibt es doch bis jetzt mehrere Wege:
1. Zurück zu Windows und Linux in die Tonne treten
wäre Schade, denn von Win wollte ich ja weg.
2. Dual-boot
ist nicht richtig Win und nicht richtig Linux.
Wozu brauche ich Linux, wenn ich auf Win sowieso nicht verzichten
kann?
3. virtualbox mit Win
Prinzipiell wie 2.
4. wine
läuft langsam aber läuft. Für gelegentliche Wartung möglicherweise
vertretbar.
Da es Lösungen für das Problem gibt, muss ich mich doch nur fragen, ob
ich mit den jeweiligen Einschränkungen leben kann, oder ob ich Linux den
Rücken kehre.
Eine ältere Anwendung laufen zu lassen, egal ob ein Compiler oder etwas
anderes, ist für einen Windows-User keine "EXTREM andere Bedingung"
sondern eigentlich der Normalzustand.
Man muss doch bedenken, dass es in der Windows-Welt nicht alles für lau
gibt, wie bei Linux. In so fern nutzt man gekaufte Software auch so
lange, wie diese den Ansprüchen gerecht wird.
Ich glaube kaum, dass andere Win-Nutzer jedes Jahr mehrere Tausend €
bezahlen, um immer die letzten Programmversionen zu haben. Das machen
weder Privatleute noch Grossunternehmen!
WinAVR gab es zwar kostenlos, aber das ändert doch den Grundsatz nicht,
dass es bei einem OS erst einmal von Vorteil ist, wenn man nicht
gegängelt wird, immer die neuesten Programmversionen benutzen zu müssen.
Zudem gibt es in der Linux-Welt auch noch weitere Baustellen für mich,
zu denen ich noch gar keine Lösung habe (z. B. e-books +
.pdf-Zeitschriften aus der Stadtbücherei, die verschlüsselt sind und nur
für den Ausleihezeitraum freigeschaltet werden). Details dazu gehören
nicht in dieses Forum.
Das sind auch keine "EXTREM anderen Bedingungen" sondern
Standard-Anwendungen in Windows. Allerdings habe ich schon die Erfahrung
gemacht, dass es bei manchen "Linux-Extremisten" nicht gern gesehen ist,
wenn man als Linux-Anfänger Fragen stellt, die nur schwer zu beantworten
sind.
Und da ich ein netter Mensch bin, und andere nicht verärgern möchte,
habe ich ein Problem: da ich vor der Fragestellung nicht weiss, ob es
eine Lösung gibt (und die Frage damit genehm ist), weiss ich auch vorher
nicht, welche Fragen ich stellen darf, ohne dass meinem Gegenüber der
Kamm schwillt.
wendelsberg schrieb:> eine Linuxtoolchain, die auf Windows gefrickelt wurde, dann unter einem> simulierten Windows auf einem Linux laufen zu lassen, ist schon ziemlich> abwegig, um nicht zu sagen, pervers.
Es ist keine „Linuxtoolchain“, sondern eine plattformübergreifende
Toolchain, also eben genau das, was die meisten sonst unter Windows
üblichen Dinge auch im dritten Jahrtausend leider nach wie vor noch
nicht sind. GCC ist viel älter als Linux, nicht vergessen. ;-)
Da ist auch nichts auf Windows „gefrickelt“ worden. Das geht dort
wie unter Linux oder FreeBSD oder Solaris: man packt das Zeug aus
und compiliert es. Wesentlicher Unterschied: man muss sich vorher
auch noch einen Compiler installieren, denn der Luxus, sowas gleich
ab Haus mit dabei zu haben, ist dem Windows-Nutzer nicht vergönnt.
Allerdings läuft der GCC aus mir nicht wirklich verständlichen Gründen
(im Wesentlichen muss er ja nur Dinge aus Dateien einlesen, verarbeiten
und wieder in Dateien schreiben, was eigentlich alles OS-unabhängig ist
und mit purem Standard-C zu erledigen wäre) unter Windows schon immer
mehrfach langsamer als auf vergleichbarer Hardware unter Unix. Keine
Ahnung, warum das so ist, aber dass er unter Wine dann natürlich lahm
ist, ist folglich kein Wunder.
Nero schrieb:> 3. virtualbox mit Win> Prinzipiell wie 2.
Nö, nicht ganz. Man kann beides parallel laufen lassen. Gerade für
eine Migrationsphase ist das sicher gar nicht so schlecht. (Ich
mach das in der Firma aus anderen Gründen auch.) Hat den zusätzlichen
Vorteil, dass du nach der ach so üblichen Meldung „Sie müssen jetzt
Ihr System neu starten, damit die Updates aktiviert werden können.“
getrost das Windows in die Ecke legen kannst und erstmal ganz normal
mit dem Rest weitermachst. Wenn Windows sich dann in einer halben
Stunde ausgekäst hat, gehst du dir mal wieder die VirtualBox angucken.
:)
> Da es Lösungen für das Problem gibt, muss ich mich doch nur fragen, ob> ich mit den jeweiligen Einschränkungen leben kann, oder ob ich Linux den> Rücken kehre.
Oben tust du so, als würdest du das nur zur Pflege eines Stückchen
alten Codes benötigen. Dafür ist doch ein brauchbarer Workaround
völlig ausreichend, auch wenn er nun nicht unbedingt schnell ist.
Dein Fazit wieder liest sich aber so, als wäre es für deine weitere
Arbeit ein völliges K.O.-Kriterium, dass der alte Mist auf immer und
ewig so weiterläuft, also als würdest du ihn doch gern zur täglichen
Arbeit nehmen wollen.
> Eine ältere Anwendung laufen zu lassen, egal ob ein Compiler oder etwas> anderes, ist für einen Windows-User keine "EXTREM andere Bedingung"> sondern eigentlich der Normalzustand.
Von einem Programm jedoch sowohl eine uralte als auch eine aktuelle
Version parallel laufen zu haben, ist auch dort keineswegs so normal.
Es gibt Programme, die unterstützen das, aber eben nicht jedes.
Nero schrieb:> Leider reicht dieses "umreißen" für einen Linux-DaU nicht. Da würde ich> schon eher eine Art Kochbuch benötigen, dass damit anfängt, welche> Toolchain ich installieren müsste, um den Compiler zu compilieren? Habe> da absolut keinen Plan.http://www.nongnu.org/avr-libc/user-manual/install_tools.html> Habe ich gemacht, die .deb konnte ich trotzdem nicht installieren.> Keinen Schimmer warum.
„Geht nicht“ ist allerdings keine Fehlermeldung, mit der du in
irgendeiner Form eine Hilfe erwarten kannst. (Dieser Spruch war der
erste, den ich meinem Sohn beigebracht habe, als er angefangen hat,
Python zu programmieren. ;-) Ein paar mehr Details müsstest du also
schon zum besten geben.
> welche Toolchain ich installieren müsste, um den Compiler zu> compilieren?
Alle grundlegend dafür nötigen Dinge sind halt im Gegensatz zu
Windows bereits Bordmittel eines üblichen Unix. (OK, von OSX mal
abgesehen, da muss man sich den Compiler auch als XCode erstmal
installieren.)
Jörg Wunsch schrieb:> Allerdings läuft der GCC aus mir nicht wirklich verständlichen Gründen> (im Wesentlichen muss er ja nur Dinge aus Dateien einlesen, verarbeiten> und wieder in Dateien schreiben, was eigentlich alles OS-unabhängig ist> und mit purem Standard-C zu erledigen wäre) unter Windows schon immer> mehrfach langsamer als auf vergleichbarer Hardware unter Unix. Keine> Ahnung, warum das so ist,
Das kann man erklären. Damit das schön plattformunabhängig funktioniert,
nutzt gcc eine C-Library, die auf Posix-Funktionen aufsetzt. Die
Posix-Funktionen in Windows wurden aber ursprünglich nur programmiert,
damit die ersten NT's mit einem "Posix-Compatible"-Logo auf der
Schachtel ausgeliefert werden konnten (damals war das wohl noch was
wert) und (wahrscheinlich) seither nie wieder angefaßt.
Ich verstehe trotzdem nicht, warum sich Nero nicht auf seinen Hosenboden
setzt und sich die Toolchain, die er braucht, mal eben selber bäckt.
Wenn man weiß, wie's geht, braucht das nur wenig mehr Zeit, als der
Beitrag hier gebraucht hat. Beim ersten Mal dauert's vielleicht
tatsächlich ein paar Stündchen, aber am Ende weiß man wenigstens,
warum man Linux einsetzt.
Daß es nix kostet ist nämlich der allerkleinste seiner Vorteile.
Markus F. schrieb:> Damit das schön plattformunabhängig funktioniert, nutzt gcc eine> C-Library, die auf Posix-Funktionen aufsetzt.
Nein. Da ist nix mit Posix drin, dass ist alles plain old Standard
C (bis auf einige wenige Funktionen, die auf die Win-Registry
zugreifen, um die Lage der Komponenten zu ermitteln). Also nix mit
read(), write() etc, sondern fread(), fwrite() und sowas.
Die Standard-C-Funktionen wiederum werden durch das benutzte MinGW
einfach auf die Win32-API-Aufrufe geschoben (ähnlich, wie eine
Posix-C-Bibliothek sie halt auf die Posix-Aufrufe abbilden würde).
Applikationen, die das Posix-API benutzen, bekommt man unter MinGW
nicht gebaut; für diese muss man Cygwin benutzen. Bei den in WinAVR
enthaltenen Dingen trifft dies meines Wissens nur auf AVaRICE zu
(welches in der Tat mit dem Fokus auf das Posix API entwickelt worden
ist).
Genau darum wundert mich das immer wieder, dass Windows beim Compilieren
derart lahm ist. Ist ja auch nicht so, dass ein IAR da großartig
schneller wäre, und der läuft nun rein nur unter Windows.
Nero schrieb:> Wie sollte ich dann wissen, dass der neue Compiler jede Wenge> Warnmeldungen ausgibt, wenn er es überhaupt nicht übersetzt?
Auf Seiten von avr-gcc gab es von Version 3.4 bis 4.9 genau 4
Änderungen, die dazu führen können, dass Code, der ehemals übersetzbar
war, zu einer Fehlermeldung führt:
1) Variablen, die per Attribut __progmem__ ins Flash lokatiert werden,
müssen const sein (4.6).
2) Funktionen mit Attribut __signal__ bzw. __interrupt__ (in
AVR-Libc-Sprech: ISRs) müssen vom Prototyp "void func (void)" sein
(4.7).
3) Der Compiler bricht mit einer Fehlermeldung ab, wenn eine Funktion
sowohl als "OS_task" als auch als "OS_main" attributiert ist (4.7).
4) Option -mshort-calls wurde entfernt (4.8).
ad 1) Siehe GCC 4.6 Release Notes. Variablen im Flash müssen nicht
schreibbar sein. Falls Werte wie Seriennummer, Kalibrierdaten etc.
durch einen Bootloader-Machanismus angepasst werden, dann ist "const
volatile" die korrekte Qualifizierung.
ad 2) Anwendungsfälle, die ISRs benötigen, die nicht vom Prototyp "void
func (void)" sind, sind reichlich pathologisch und dürften kaum in
realen Programmen auftauchen.
ad 3) Offenbar ein Anwenderfehler, wenn beide Attribute angegeben
wurden.
ad 4) Siehe GCC 4.8 Release Notes. Die Option wurde entfernt, da
notorisch von Anwendern falsch verwendet, was zu unnötiger Verwirrung
und unnötigen Supportanfragen führte. -mrelax ist ein robuster Ersatz.
Jörg Wunsch schrieb:> Wesentlicher Unterschied: man muss sich vorher> auch noch einen Compiler installieren, denn der Luxus, sowas gleich> ab Haus mit dabei zu haben, ist dem Windows-Nutzer nicht vergönnt.
Bei allem nötigem Respekt, du hast anscheinend noch nie versucht, mal
Linuxgedöns unter Windows zu kompilieren. Das IST ein Albtraum.
Es fehlt ja nicht nur der Compiler. Es fehlt alles. Da braucht's mal
eben die passende Shell, gerne auch noch Python, um nur configure
durchlaufen zu lassen. Scheitert trotzdem gerne schon an der Stelle.
Danach geht es dann weiter mit fehlenden Tools, an die 20-30 fehlenden
libs, und so weiter. Spaß macht das nicht.
Oliver
Oliver S. schrieb:> Bei allem nötigem Respekt, du hast anscheinend noch nie versucht, mal> Linuxgedöns unter Windows zu kompilieren.
Selten, ja, ich weiß, Spaß macht es nicht.
Hier geht es aber nicht um „Linuxgedöns“ (was soll der abwertende
Begriff überhaupt?), sondern um GCC und seine benachbarten Tools.
Aber das ist jetzt völlig abschweifend, in diesem Thread geht es
schließlich darum, den AVR-GCC in einer alten Version unter Linux
zu compilieren. Wenn du zu dem anderen Thema diskutieren willst,
dann öffne bitte einen eigenen Thread (aber dann unter
„PC-Programmierung“).
Nero schrieb:> Habe ich gemacht, die .deb konnte ich trotzdem nicht installieren.> Keinen Schimmer warum.
Was Du wirklich gemacht hast, bleibt natürlich geheim.
Falls noch Interesse besteht:
Der Compiler aus dem Paket läuft auf neueren Debians wegen fehlender
alter libs nicht mehr. Hier habe ich eine statisch gelinkte Version
gefunden:
http://www.wrightflyer.co.uk/avr-gcc/
Damit das .deb auf einem aktuellen Debian installiert werden kann, muss
die Steuerdatei angepasst werden:
Verzeichnis anlegen:
1
leo@cb:/tmp$ mkdir deb
2
leo@cb:/tmp$ cd deb
Debian-Paket auspacken:
1
leo@cb:/tmp/deb$ ar x ../avr-gcc-4.3.3-avrfreaks-25-feb-2010-special-static.deb
Die Steuerdatei (control) auspacken:
1
leo@cb:/tmp/deb$ tar xzf control.tar.gz
Steuerdatei mit Lieblingseditor öffnen und in alle Leerzeilen einen
Punkt einfügen (" ."):
Das Verhalten des TO kommt mir immer mehr vor wie:
"Ich will das aber, Ihr muesst mir das Befehl fuer Befehl erklaeren,
sonst finde ich Linux !&&*(%%^$%&##%&^&*) !!!!!!"
Und mit der Einstellung wird das meiner Erfahrung nach nichts.
wendelsberg
wendelsberg schrieb:
>Ich will das aber,.....sonst finde ich Linux ....
Erst einmal will ich das nicht, sondern ich benötige das. Die Gründe
habe ich umfassend dargelegt.
Weiterhin weiss ich, dass das, was ich benötige, mit Windows
funktioniert.
Die Frage ist doch nicht, wie ich Linux finde, sondern allein, ob ich
mein Anforderungsprofil auch mit Linux ebenfalls erfüllen kann und dass,
ohne erst jahrelange Linux-Erfahrung zu sammeln.
Wenn ich meine Anforderungen z. B nur mit Win oder OS2 oder ... erfüllen
kann, dann kann ich Linux noch so gut oder schlecht finden wie ich will.
Es wäre dann für mich nicht zu gebrauchen.
Im übrigen setzt sich bei mir langsam der Eindruck fest, dass du mich
absichtlich falsch verstehen möchtest, mit dem Zweck, hier zu stänkern.
Du hast deine Meinung zu meinem Problem schon dargelegt und irgendwie
scheint es dir nun nicht in den Kram zu passen, dass andere User mir bei
der Lösung behilflich sind.
Es ist doch so: niemand ist verpflichtet hier mitzulesen oder sein
Wissen weiterzugeben.
Allen Usern, die konstruktiv zur Problemlösung beitragen, deshalb
nochmals meinen Dank.
Auf soche Beiträge, wie du sie ablieferst, kann ich aber verzichten.
Leo C. schrieb:
>Falls noch Interesse besteht:>.....>Paket kann jetzt installiert werden
Recht vielen Dank für die ausführliche Beschreibung!
Die Installation hat danach auch funktioniert.
Ich bin einen grossen Schritt weiter, jedoch leider immer noch nicht am
Ziel, denn der Compiler wird nicht gefunden.
Ausgangssituation mit welcher compilieren möglich war:
- aktuelle Toolchain über die Paketverwaltung
- Geany als Linux-Ersatz für Programmers Notepad
Was ich dann gemacht habe:
- avr-gcc, binutils, avr-libc deinstalliert
- nach Anleitung von Leo die .deb bearbeitet und installiert
- gemäß Beschreibung unter http://www.wrightflyer.co.uk/avr-gcc/
(The tools will be installed in /usr/local/avr with the commands
in /usr/local/avr/bin)
geprüft dass die Dateien dort wirlich sind.
- gemäß Beschreibung unter http://www.wrightflyer.co.uk/avr-gcc/
(That directory is not automatically added to the PATH so to use the
package after installation use 'export PATH=$PATH:/usr/local/avr/bin')
Also Terminal und PATH=$PATH:/usr/local/avr/bin eingegeben.
- Mit Geany ein Projekt geöffnet und zu compilen versucht
Im Ausgabefenster erscheint: sh: 1: avr-gcc: not found
Was kann denn jetzt noch der Grund dafür sein?
Nero schrieb:> Also Terminal und PATH=$PATH:/usr/local/avr/bin eingegeben.> - Mit Geany ein Projekt geöffnet und zu compilen versucht
Hast Du Geany denn in dem Terminal mit dem erweiterten PATH gestarted?
Das würde ich aber sowieso nicht so machen. "Normalerweise" hat man ja
in '/usr/bin' den aktuellen Compiler. Der würde dann zuerst gefunden.
Stattdessen schreibe in das Makefile der alten Projekte ungefähr so
etwas:
ich mag keine Binaries in Pfaden, wo sie nicht hingehören. Was zum
System gehört, gehört nach /usr/bin, was nachträglich oder irgendwie
speziell installiert wurde, gehört nach /usr/local/bin. Find' ich (und
nicht nur ich).
1
for i in /usr/local/avr/bin/*; do ln -sf $i /usr/local/bin/$(basename $i);done
/usr/local/bin ist normalerweise in $PATH, dann spart man sich das
Aufnehmen des zusätzlichen Verzeichnisses. Vielleicht vorher noch
überprüfen, ob es bereits gleichnamige Binaries in /usr/local/bin gibt.
Markus F. schrieb:> ich mag keine Binaries in Pfaden, wo sie nicht hingehören.
Wenn du aber neben einer aktuellen noch eine prähistorische Version
eines Compilers vorhalten möchtest / musst, dann hat es schon Sinn,
sie abseits der standardmäßigen Trampelpfade zu platzieren und dann
nur bei Bedarf von da hervorzukramen.
Markus F. schrieb:> ...
Ja, so macht man das, oder sollte es, in der Regel. Aber
der Pfad, um den es hier geht, ist in dem Paket so festgelegt. Lohnt
einfach nicht, daran irgendwas zu ändern. Schließlich soll der alte
Compiler nur vorübergehend installiert werden (nehme ich doch an :),
und mit einem
'dpkg --remove avr-gcc-4.3.3-avrfreaks-25-feb-2010-special-static' ist
der Kram wieder weg. Deine Symlinks hängen dann aber noch rum.
Nicht jedes binary muß, bzw. sollte, über PATH erreichbar sein. PATH ist
eine Bequemlichkeitseinrichtung für die interaktive Shell. avr-gcc wird
aber in der Regel über make oder ein anderes Build-System gestartet.
Wie installierst Du denn bei Deinem dogmatischen Schema 2, 3, oder mehr
Compilerversionen parallel?
Ich seh' gerade, daß Jörg schon im gleichen Sinne, aber mit viel weniger
Worten geantwortet hat...
Hallo zusammen!
Ich kann glücklicherweise berichten, dass alles funktioniert!!
Zuvor hatte ich den Fehler gemacht, einfach das Makefile von der
WinAVR-Version direkt in Linux zu verwenden. Dort standen dann noch
Dinge wie:
DIRAVR = c:/winavr-20100110.
Die aktuelle gcc Version über die Paketverwaltung hatte das trotzdem
problemlos geschluckt und nicht einmal eine Meldung gebracht. In so fern
kam es mir dann beim alten gcc4.3.3 nicht in den Sinn, etwas zu ändern.
Für User, welche ein ähnliches Problem haben und über die Suchfunktion
kommen, möchte ich noch anfügen, dass es mit den Erweiterungen von Leo
im meinem Makefile noch nicht ganz getan war. Die Änderungen in
folgenden Zeilen waren noch nötig:
avr-nm -n $< > $@ -> $(NM) -n $< > $@
avr-size -B -d $(TARGET).elf -> $(SIZE) -B -d $(TARGET).elf
avr-size -B -d $(OBJ) -> $(SIZE) -B -d $(OBJ)
@avr-size -C --mcu=${MCU} ${TARGET}.elf -> @$(SIZE) -C --mcu=${MCU}
${TARGET}.elf
Jetzt rennt der Compiler wie ein Blitz. Es ist ja die identische
Toolchain-Version wie unter Windows. Trotzdem ist der Compiler unter
Linux mehr als doppelt so schnell!
Einen derartigen Zuwachs an Geschwindigkeit hätte ich nicht vermutet!
Nochmals meinen Dank an alle Beteiligten!
Nero schrieb:> Trotzdem ist der Compiler unter Linux mehr als doppelt so schnell!
Sach' ich doch. Das ist auch mir unverständlich …
Aber schön, wenn das jetzt für dich funktioniert!
Jörg Wunsch schrieb:> Das ist auch mir unverständlich …
Wenn ich mich recht erinnere, hängt das mit dem Festplattenzugriffen des
gcc zusammen. Irgendwie war das so, daß der so ziemlich jedes Zeichen
einzeln von der Platte holt, was Windows einfach nicht mag.
Oliver
Leo C. schrieb:> Wie installierst Du denn bei Deinem dogmatischen Schema 2, 3, oder mehr> Compilerversionen parallel?
"dogmatisch" ist ein Fremdwort für mich ;). Ich bin ein fauler Hund und
mach's so, wie's nachher für mich selbst am wenigsten Arbeit ist.
Weil ich ein (zugegebenermaßen möglicherweise seltsam anmutendes) Faible
für allerlei Prähistorisches habe und meine Compiler deshalb sowieso
selber bauen muß:
1
ls /usr/bin/m68k-elf*gcc*
2
3
m68k-elf-gcc-2.95
4
m68k-elf-gcc-3.3
5
m68k-elf-gcc-4.6.3
6
m68k-elf-gcc-4.6.4
7
m68k-elf-gcc
Der "ohne Nummer" zeigt auf den, den ich dann meist nutze.
Oliver S. schrieb:> ziemlich jedes Zeichen einzeln von der Platte holt
Das geht ja schon deshalb nicht, weil man immer mindestens 512 Zeichen
am Stück von der Platte bekommt. :-)
Pufferung ist eine Aufgabe von stdio, das konnten die schon vor 40
Jahren auf 'ner PDP-11.
Jörg Wunsch schrieb:> Pufferung ist eine Aufgabe von stdio, das konnten die schon vor 40> Jahren auf 'ner PDP-11.
Da hat Bill Gates aber nicht drauf gelernt ;)
Oliver
Oliver S. schrieb:
> ziemlich jedes Zeichen einzeln von der Platte holt
D.h. Linux macht simpelste Dinge richtig, die man unter Windows dem
Anwendungsprogramm überlässt? Dieses ist ja in beiden Fällen das
Gleiche. Eigentlich mag ich ja Linux lieber, woran MS mit jeder Version
mehr arbeitet, aber daß Windows allein der Grund sein soll, für so
miserable IO-Performance, kann ich kaum Glauben. Sicher werden die
Sourcen beim Lesen noch auf Viren überprüft ;-)
Bastler schrieb:> Sicher werden die Sourcen beim Lesen noch auf Viren überprüft ;-)
Wenn du deinem Virenchecker erzählst, dass er das so tun soll: na klar.
Thread beobachten
Seitenaufteilung abschalten