Hallo zusammen,
ich habe mir einen avr-gcc 4.8.4 gebaut, da es in meiner Linux-Mint
Distri nur den 4.7.2 über die Paketverwaltung gibt.
Mittels "configure", "make" und "make install" habe ich den Compiler
gebaut und installiert.
Soweit ich sehe hat das auch geklappt:
Soweit nachvollziehbar, denn die avr-libc hab ich nicht gebaut. Da würd
ich gern weiterhin die über die Paketverwaltung installierte Version
(1.8.0) benutzen.
Nur wie krieg ich meinen neuen gcc dazu, weiterhin die alte avr-libc
(die wohl irgendwo in /usr liegt) zu benutzen?
Ehrlich gesagt musste ich da noch nie irgendwas einstellen, das "hat
alles immer so funktioniert".
Kann mir da wer helfen?
Was macht die hoffnungsvoll, daß die "alte" Lib kompatibel zum "neuen"
AVR-GCC-Code ist? Ich habe auch Selbstbau-GCG's im Einsatz und da gehört
ein Neuübersetzen der avr-libc einfach mit dazu. Schon damit die vom
"besseren" Compiler profitiert. Da ist ja auch nicht viel zu tun, nur
auf das Ende von make warten. Das ist auch ein erster (sehr grober)
Testlauf für den neuen gebauten Compiler.
Bastler schrieb:> Was macht die hoffnungsvoll, daß die "alte" Lib kompatibel zum "neuen"> AVR-GCC-Code ist?
Daran habe ich ehrlich gesagt nicht gedacht. Sollte aber in Erfahrung zu
bringen sein wie die Lib gebaut wurde. Aber ja, zwischenzeitlich hab ich
mir mal die Sourcen der Lib besorgt und einen Build-Versuch gestartet.
Bastler schrieb:> Da ist ja auch nicht viel zu tun, nur> auf das Ende von make warten
Da liegt der Hund begraben: soweit komm ich garnicht.
Das configure der avr-libc scheitert. Im config-log finde ich auch den
Fehler.
Sinngemäs: mein avr-gcc kennt die Option "-V" nicht (logisch, muss ja
auch "-v" lauten).
Ich bin gerade nicht an der Maschine, sonst würd ich den ganzen Log
posten.
Läuft bei dir alles sauber durch? Musstest du irgendwo fummeln?
Ansonsten, rein aus sportlichem Ehrgeiz nochmal die Eingangsfrage: woher
weis ein avr-gcc, wo er die avr-libc findet?
Interessieren würds mich noch. Hab irgendwie Bedenken dass er meine
selbstgebaute Lib (sollte sie mal kompilieren) dann genauso wenig
findet.
Hast du den Path auch richtig gesetzt? Am einfachsten testet man das mit
"avr-gcc -v", dann müßte, neben ein paar Fehlermeldungen,) die "neue"
Versionsnummer erscheinen. Das configure meint der avr-gcc passe nicht,
läst den falschen Pfad vermuten.
Achja, ich mache das immer so:
http://www.nongnu.org/avr-libc/user-manual/install_tools.html
Meist via c&p, denn so oft brauch ich das ja nicht. Ich hoffe du
werkelst auf einem richtigen Betriebssystem. Mit dem bekannten
Kommerziellen wollte ich das bisher noch nie probieren. (Auch weil dort
immer weniger wirklich besser lief, als bei dem Anderen, dem Freien.)
Bastler schrieb:> Hast du den Path auch richtig gesetzt? Am einfachsten testet man das mit> "avr-gcc -v", dann müßte, neben ein paar Fehlermeldungen,) die "neue"> Versionsnummer erscheinen. Das configure meint der avr-gcc passe nicht,> läst den falschen Pfad vermuten.
Jep, die Symlinks in /usr/bin zeigen auf "meinen" gcc.
"avr-gcc -v" liefert die erwartete (neue) Version.
Das Problem ist, das configure der avr-libc testet mit einem "avr-gcc
-V" (man beachte das große "-V") und bricht deswegen ab.
Bastler schrieb:> Achja, ich mache das immer so:> http://www.nongnu.org/avr-libc/user-manual/install_tools.html> Meist via c&p, denn so oft brauch ich das ja nicht.
Genau an die Anleitung habe ich mich auch gehalten.
Nur bricht eben bei mir configure ab. Kann mir aber irgendwie nicht
vorstellen dass sich da ein Fehler ins Script eingeschlichen hat...
Vielleicht schaut ja Jörg Wunsch hier mal vorbei :-)
Bastler schrieb:> Ich hoffe du> werkelst auf einem richtigen Betriebssystem
Ja :-)
Gerade mal geschaut: GCC kennt kein großes V als Commandline-Parameter.
Scheint ein Problem im Script zu sein. Zumal das Ermitteln der
Compilerversion ja sinnvoll wäre.
SVN der AVRlibc wurde übrigens (nicht von Jörg) vor 3 Wochen wegen " bug
#44869: detect compiler version and install crt and device library in
requir..." geändert. Benutz einfach mal nicht die allerneuste Version.
Schließlich ist auch dein Compiler eher konservativ versioniert. Zu 5.0
wird das Thema AVRlibc komplett neu aufgerollt. Ich hab als erstes eine
5.x kompatiblen Verzeichnes-/Dateibaum erstellt (und so etwas Python
gelernt), bevor avr-gcc 5.x laufen wollte. Gut daß mein OS sowas
mitmacht :-)
Wert ich probieren, danke.
War es mühselig den 5.x gcc zu bauen?
Ich selbst bin daran gescheitert, deswegen auch der "konservative"
4.8.4, den hab ich gebaut gekriegt.
Problem beim 5.x war übrigens das allergleiche wie bei der avr-libc,
irgendein Script ruft den gcc mit -V auf, und das klappt nicht.
Hm, irgendwie riecht das alles danach als würde bei mir irgendwas nicht
passen...
Bis 4.9.2 ist alles C&P nach Anleitung. Bei 5.x hatte ich das Problem,
daß wohl die Struktur der AVRlibc anders ist, nun geht's wohl eher um
"Device-Klassen" als um einzelne Devices, was ja bei x
Silizium-Varianten des programmtechnisch gleichen Devices sinnvoll ist.
Nur erwartet nun der Compiler/Linker einen ganz anderen Verzeichnisbaum
der Libs. Ein mehrstündiger Python-os.irgendwas-Lib-Kurs hat aber
geholfen. Später kann ich das ja mal posten, vom iPad aus geht das wegen
"nicht da" schlecht. Allerdings bringt 5.x (im Vergleich zu 4.9.2)
bisher nur einige C++ Details mehr. Ein Beispiel-Projekt war identisch,
bis auf eine Stelle, wo man durch andere Registerbelegung ein Move hätte
sparen können. Bei 5.x wohlgemerkt. Ein anderes Projekt hat aber 2..3%
von besseren "Nicht-Backend"-Optimizer profitiert. Ich werde aber noch
abwarten, bis der sich etwas gesetzt hat.
Und ich glaube zwischen 4.8 und 4.9 wurde der GCC auf C++ umgestellt, da
muß man diverse Pakete nachinstallieren. Also make, Fehler anschauen,
Paket identifizieren/installieren, und LOOP bis alles paßt.
Pascal schrieb:> Das configure der avr-libc scheitert. Im config-log finde ich auch den> Fehler.> Sinngemäs: mein avr-gcc kennt die Option "-V" nicht (logisch, muss ja> auch "-v" lauten).
Das ist ganz gewiss nicht das Problem. configure probiert dabei
nur ein paar Varianten durch.
Poste mal das komplette config.log, aber bitte als Anhang und vielleicht
auch komprimiert (.bz2). Die Dinger sind groß.
Hallo Jörg Wunsch,
zwar bisl verspätet (ich hab nicht immer Zugriff auf die Maschine), aber
hier ist der Log.
Vielleicht kannst du kurz drüber schaun?
Das "-V" Problem erhalte ich auch, wenn ich den gcc 5.x baue. Der 4.8.4
läuft durch.
Außerdem tritt das Problem bei der avr-libc 1.8.0 und 1.8.1 auf.
1) GCC in seinem Quellverzeichnis (oder einem Unterverzeichnis davon)
zu configuren wird nicht unterstützt.
2) Es werden die falschen Binutils verwendet, nicht die für AVR.
Ergo: Die benötigten Tools sind nicht vorhenden bzw. fehlerhaft
generiert oder installiert oder es fehlen Pfade.
Generell sollen die Binutils mit der gleichen --prefix wie GCC und libc
auch generiert oder zumindest installiert werden.
Johann L. schrieb:> Generell sollen die Binutils mit der gleichen --prefix wie GCC und libc> auch generiert oder zumindest installiert werden.
Auch für die avr-libc bietet es sich an, wenn sie mit dem gleichen
--prefix konfiguriert wird. Wenn man nun wiederum ${PREFIX}/bin im
Pfad hat, werden die Tools auch alle ordentlich gefunden.
Pascal schrieb:> Vielleicht kannst du kurz drüber schaun?
Nur, damit du künftig weißt, wonach man gucken sollte: hier die
Erklärung für Johanns Analyse:
1
configure:3713: checking for suffix of object files
2
configure:3735: avr-gcc -c conftest.c >&5
3
/tmp/ccpQbjTL.s: Assembler messages:
4
/tmp/ccpQbjTL.s:13: Error: too many memory references for `in'
5
/tmp/ccpQbjTL.s:14: Error: too many memory references for `in'
6
/tmp/ccpQbjTL.s:19: Error: no such instruction: `ldi r24,0'
7
/tmp/ccpQbjTL.s:20: Error: no such instruction: `ldi r25,0'
8
configure:3739: $? = 1
9
configure: failed program was:
Die Fehlermeldung wiederum lässt sich nur dadurch erklären, dass der
falsche Assembler vom Compiler genutzt worden ist.
Generelles Vorgehen mit config.log: als erstes ans Ende gehen, von
da rückwärts all die Statusinformationen überspringen (in diesem Falle
sind das “Cache variables”, “Output variables” und “confdefs.h”).
Irgendwo da findet sich der eigentliche Fehler. Alle Fehlermeldungen
davor (wie die Sache mit dem -V) sind trial&error-Dinge vom configure,
die allesamt unwichtig waren, denn da ist es am Ende noch weiter
gelaufen.
>Bastler schrieb:>> Achja, ich mache das immer so:>> http://www.nongnu.org/avr-libc/user-manual/install...>> Meist via c&p, denn so oft brauch ich das ja nicht.>>Genau an die Anleitung habe ich mich auch gehalten.
Offenbar nicht ganz, sonst wären nicht die falschen binutils gestartet
worden.
...hier noch der wesentliche Auszug aus config.log:
1
configure:3735: avr-gcc -c conftest.c >&5
2
/tmp/ccpQbjTL.s: Assembler messages:
3
/tmp/ccpQbjTL.s:13: Error: too many memory references for `in'
4
/tmp/ccpQbjTL.s:14: Error: too many memory references for `in'
5
/tmp/ccpQbjTL.s:19: Error: no such instruction: `ldi r24,0'
6
/tmp/ccpQbjTL.s:20: Error: no such instruction: `ldi r25,0'
7
configure:3739: $? = 1
8
configure: failed program was:
9
[...]
10
configure:3753: error: in `/home/pas/gcc-avr/avr-libc-1.8.1/build':
11
configure:3755: error: cannot compute suffix of object files: cannot compile
Insbesondere die letzte Meldung "cannot compute suffix of object files"
sollte beim Wühlen in der allwissenden Müllhalde zahlreiche Treffer
zutage fördern.
Weiters:
1
configure:3118: checking for avr-gcc
2
configure:3134: found /usr/bin/avr-gcc
3
configure:3145: result: avr-gcc
was nicht der aktuell zu generierenden Toolchain entstammt. avr-gcc ist
nicht so konservativ wie ein Host-GCC, d.h. es kann schon mal vorkommen
— mea culpa — dass sich das ABI ändert.
Wenn Libs, Objekte oder Code dann mit unterschiedlichen Versionen bzw.
ABIs übersetzt wurden, dann holst du dir bei der Fehlersuche den Wolf;
und zwar gründlich ;-)
Thread beobachten
Seitenaufteilung abschalten