Hallo, habe mir mal wieder meine Toolchain auf avr-gcc 11.2.0 aktualisiert, wie immer mit frischen benötigten Paketen, u.a. binutils 2.37 statt Vorgängerversion 2.36.1 Baue ich die Toolchain mit binutils 2.36.1 ist alles in Butter. Baue ich mit binutils 2.37 funktioniert hinter nichts. Atmel Studio 7 meckert mit > Error recipe for target 'main.o' failed und Arduino IDE meckert je nach µC mit > as: unrecognized option `-mmcu=avrxmega3' Was auch auffällt ist das der bin Ordner in der mit 2.37 gebauten Toolchain ziemlich leer ist. Siehe Screenshots. Kurzerhand aufgefüllte Dateien aus der 2.36.1 Toolchain hilft nicht. Die Fehlermeldung bleiben gleich. Jetzt wollte ich fragen ob schon jemand mit den binutils 2.37 eine Toolchain gebaut und wie das bei ihm aussieht?
Angehängte Dateien:
-
mit_binutils_2.36.1.png
62 KB -
mit_binutils_2.37.png
35 KB
Beitrag #6776689 wurde von einem Moderator gelöscht.
Hallo, das müßtest du mir bitte genauer erklären. Ich weiß derzeit nur eins, dass es mit binutils v2.36.1 funktioniert nur mit v2.37 nicht. Nachdem die Linux Bauphase durch ist, in dessen /bin übrigens alles vollständig scheint, folgt die Windows Bauphase, die Konfigzeile für den binutils Teil sieht so aus
1 | # Binutils
|
2 | cd $HOME/toolchain/buildWindows/binutils |
3 | ../../downloads/binutils/configure --prefix=$PREFIX --target=avr --build=x86_64-linux-gnu --host=x86_64-w64-mingw32 --disable-nls --disable-werror |
build: muss Linux 64 Bit, weil gebaut wird unter Ubuntu 20.04 LTS in einer VM. host: ist ja später ein Windows 64Bit unter der der avr-gcc kompilieren soll target: avr Ich kann ehrlich gesagt keinen Fehler sehen, zudem ich das Script schon länger unverändert nutze.
Hallo Johann, kannst du mir noch einen Hinweis geben oder gibts schlichtweg keinen?
Also auf den ersten Blick scheinen da ja echt einige Programme zu fehlen. Wenn ich binutils-2.34 für avr kompiliere, kriege ich da
1 | avr-addr2line avr-c++filt avr-ld avr-objcopy avr-readelf avr-strip |
2 | avr-ar avr-elfedit avr-ld.bfd avr-objdump avr-size |
3 | avr-as avr-gprof avr-nm avr-ranlib avr-strings |
Die 2.37 habe ich momentan leider nicht griffbereit.
Auch mit dem 2.37 von https://mirrors.syringanetworks.net/gnu/binutils/ und dem windows-build gibts
1 | avr-addr2line.exe avr-elfedit.exe avr-nm.exe avr-readelf.exe |
2 | avr-ar.exe avr-gprof.exe avr-objcopy.exe avr-size.exe |
3 | avr-as.exe avr-ld.bfd.exe avr-objdump.exe avr-strings.exe |
4 | avr-c++filt.exe avr-ld.exe avr-ranlib.exe avr-strip.exe |
Ach so: ich musste in der libiberty noch zwei kleine Fehler beheben, damit die überhaupt kompiliert.
Hallo, wundert mich ehrlich gesagt. Ich probiere das nochmal mit "deinem Mirror" obwohl das ja die gleichen Dateien sein müßten. Was hast du in der libiberty geändert?
Da wurde an einer Stelle mit "uint" hantiert, was nirgendwo definiert war. Ich nehme mal an, das "unsigned" das treffende ist.
Achso: den Mirror hatte ich angeführt, weil die repos "binutils-gdb" bei mir anderweitig zu Fehlern geführt hatten, als ich mich mit toolchains auseinandergesetzt hatte (hauptsächlich im gdb Part).
Hallo, ne, da ändert sich leider nichts bei mir. Kann mir jemand sagen was Johann mit Host-Tools konkret meint? Möglicherweise bin ich Begriffsstutzig.
Vermutlich, dass der falsche Assembler aufgerufen wird. Bin mir nicht sicher, wie der lookup da funktioniert, aber avr-as ist jedenfalls eines der Programme, die bei dir in der neuen Version fehlen.
Bei genauerem Hinsehen scheint da kein einziges Program der binutils im Ordner zu sein.
Hallo, naja, meine Frage lautete ja warum fehlen die Programme bei mir? Woran kann das liegen? Johann vermute daraufhin was mit Host-Tools. Ich kann aber damit nichts anfangen. Ich dachte zuerst er meint die Parametrierung mit host und target, dass kanns aber nicht sein was er vielleicht meint.
Die dumme Frage: Werden die binutils auch installiert? Kannst du von dem build usw. mal ein log posten?
avr-gcc (Treiber) ruft nich avr-as auf sondern den as, der gefunden wird. Schau dir Ausgabe von -v oder -### an. as steht normal im gleichen Verzeichnis wie cc1, cc1plus, lto1 etc.
Angehängte Dateien:
-
Ordner.jpg
61 KB
Hallo, as gibt es nicht. Ordnerinhalt siehe Bild. Die Ausgabe mit -v in AS7 ist die Eingangs gezeigte: Error recipe for target 'main.o' failed Mehr gibts da nicht zu sehen. Außerdem treibt mich noch die Frage um, was ist an der binutils 2.37 anders wie zur 2.36.1? Mit letzterer klappt ja alles. Ich werde mal binutils alleine bauen lassen und das Logfile zeigen ...
Hallo, hier das Logfile der binutils Bauphase. Das Script dazu sieht so aus.
1 | #!/bin/bash
|
2 | |
3 | set -x |
4 | |
5 | # Zeitnahme
|
6 | TIME_START=$(date +%s) |
7 | |
8 | # For optimum compile time this should generally be set to the number of CPU cores your machine has
|
9 | JOBCOUNT=4 |
10 | |
11 | echo " " |
12 | rm -rf $HOME/local/avrWindows64/* |
13 | rm -rf $HOME/toolchain/buildWindows/binutils/* |
14 | |
15 | PREFIX=$HOME/local/avrWindows64/ |
16 | # export PREFIX
|
17 | PATH=$PATH:$PREFIX/bin/ |
18 | # export PATH
|
19 | |
20 | # Binutils
|
21 | cd $HOME/toolchain/buildWindows/binutils |
22 | ../../downloads/binutils/configure --prefix=$PREFIX --target=avr --build=x86_64-linux-gnu --host=x86_64-w64-mingw32 --disable-nls --disable-werror |
23 | make -j $JOBCOUNT |
24 | make install |
25 | |
26 | # Zeitnahme
|
27 | TIME_END=$(date +%s) |
28 | TIME_RUN=$(($TIME_END - $TIME_START)) |
29 | echo "" |
30 | echo "Done in $TIME_RUN seconds" |
Das ist nich die Ausgabe von -v.
Es ist kein Target as installiert, daher wird der Host as genommen.
Angehängte Dateien:
-
glaube_es_mir_doch.png
98 KB
Johann L. schrieb: > Das ist nicht die Ausgabe von -v. Verstehe ich nicht. In AS7 ist die Option -v aktiv. Ausgabe ist: Error recipe for target 'main.o' failed > Es ist kein Target as installiert, daher wird der Host as genommen. Was meinst du mit "ist nicht installiert"? Wo soll es denn installiert sein? Ich meine das Dateien fehlen sehe ich ja selber. Die Frage ist warum diese fehlen?
Johann L. schrieb: > as steht normal im gleichen Verzeichnis wie cc1, cc1plus, lto1 etc. Auch das habe ich nochmal mit einer älteren gebauten Toolchain verglichen. C:\avrToolchain\avr-gcc-11.2.0_...\libexec\gcc\avr\11.2.0\ In dem Ordner fehlen keine Dateien, alles exakt gleich vorhanden. as.exe ist hier nicht vorhanden. as.exe liegt bei allen anderen Toolchains C:\avrToolchain\avr-gcc-11.2.0_...\avr\bin\ Genau der Ordner \avr\bin\ fehlt in der neu gebauten Toolchain. Habe den Ordner von der vorherigen Toolchain kopiert. Danach ging immer noch nichts. Ich musste feststellen das auch der Ordner C:\avrToolchain\avr-gcc-11.2.0_...\avr\lib\ldscripts\ komplett fehlt. Habe ihn ebenfalls von der vorherigen Toolchain mit binutils 2.36.1 kopiert. Jetzt kann ich kompilieren. Meine Frage lautet aber weiterhin, warum fehlen die vielen Dateien nachdem Bau der Toolchain mit binutils 2.37? Normal ist das ja nun nicht. Man sitzt bestimmt immer auf einem kleinen Pulverfass.
Im Log kommen viele solche Zeilen vor:
1 | make[1]: Verzeichnis „/home/ubuntixer/toolchain/buildWindows/binutils“ wird betreten |
2 | make[1]: Für das Ziel „all-target“ ist nichts zu tun. |
Das Script sollte ja das build-Verzeichnis säubern - das fehlte hier wohl leider. Da wurden nur ein paar libs und manpages bearbeitet. Die config.log Datei aus dem build-Verzeichnis wäre auch nicht schlecht zu sehen. PS: Auf dem System scheint locale nicht richtig konfiguriert zu sein (Siehe Umlaut). Ich würde da irgendwas *.UTF-8 einstellen.
Hallo, Spracheinstellung sieht so aus, sollte passen. Kann ich für dich noch woanders was ändern?
1 | $ locale |
2 | LANG=de_DE.UTF-8 |
3 | LANGUAGE=de_DE:en |
4 | LC_CTYPE="de_DE.UTF-8" |
5 | LC_NUMERIC=de_DE.UTF-8 |
6 | LC_TIME=de_DE.UTF-8 |
7 | LC_COLLATE="de_DE.UTF-8" |
8 | LC_MONETARY=de_DE.UTF-8 |
9 | LC_MESSAGES="de_DE.UTF-8" |
10 | LC_PAPER=de_DE.UTF-8 |
11 | LC_NAME=de_DE.UTF-8 |
12 | LC_ADDRESS=de_DE.UTF-8 |
13 | LC_TELEPHONE=de_DE.UTF-8 |
14 | LC_MEASUREMENT=de_DE.UTF-8 |
15 | LC_IDENTIFICATION=de_DE.UTF-8 |
16 | LC_ALL= |
Config.log liefere ich nach, muss ich neu bauen, hatte soeben experimentiert.
Veit D. schrieb: > Spracheinstellung sieht so aus, sollte passen. Kann ich für dich noch > woanders was ändern? Aber, ja! :) LANG ist keine UTF-8 locale. Das ist heutzutage eher unüblich, ich bin mir aber nicht sicher, ob es echt ein Problem darstellt. Manche tools wie "sort" usw. sind locale-sensitive.
Ich frage mal anders herum: Woher hast du die sourcen von biinutils?
von hier: http://ftp.gnu.org/gnu/binutils/ Wegen der Spracheinstellung. Ich habe zwischenzeitlich mehrere Anleitungen zur Spracheinstellung gelesen. Die sehen alle wie meine aus bzw. werden so konfiguriert. ??? Tut mir leid. Wenn es noch irgendein Tipp gibt die Kompatibilität zu verbessern, nur zu.
Veit D. schrieb: > Tut mir leid. Wenn es noch irgendein > Tipp gibt die Kompatibilität zu verbessern, nur zu. Ja, das ist wahrscheinlich nichts. > von hier: http://ftp.gnu.org/gnu/binutils/ Das sind die selben, die ich auch erstellt hatte. Tja... in deinem Log fehlten wie gesagt die builds von einigen targets. Solltest du nochmal ein neues Log anfertigen, lass bitte das "-j 4" beim make weg. Das macht das Log ziemlich schwer nachzuvollziehen.
Al Fine schrieb: > Tja... in deinem Log fehlten wie gesagt die builds von einigen targets. > Solltest du nochmal ein neues Log anfertigen, lass bitte das "-j 4" beim > make weg. Das macht das Log ziemlich schwer nachzuvollziehen. Wäre gerade fertig gewurden. Ohne "-j 4" mache ich morgen. Ist ja kein Problem.
Hallo, habe es mit einem Kern laufen lassen. ;-) Enthalten sind Abschnittsweise alle Terminalausgaben und hoffentlich die Richtigen der gewünschten build Logfiles. Beim überfliegen sehe ich erstmal keine falschen Umlaute. Mal sehen wie das bei dir ist. Wenn du mir sagst wonach du in den Logfiles genau suchst könnte ich mitmachen.
Veit D. schrieb: > Wenn du mir sagst wonach du in > den Logfiles genau suchst könnte ich mitmachen. Nach Auffälligkeiten :) Sehe nur leider nicht viel. "iconv" ist offenbar nicht installiert - glibc also auch nicht. Ob mawk für den job genügt, weiß ich nicht sicher. bison ist auch nicht da, scheint aber keinen Unterschied zu machen. Dein Build wechselt nicht mal in die binutils und gas Unterverzeichnisse.
Hallo, zum bauen hatte ich bis jetzt immer nur
1 | > sudo apt-get install aptitude |
2 | |
3 | > sudo aptitude install build-essential autoconf automake libtool mingw-w64 subversion |
4 | |
5 | > sudo aptitude install texinfo |
installiert.
Hallo, eine Neuinstallation der Software unter Linux die man zum bauen benötigt brachte auch keinen Erfolg. Irgendwelche anderen Vermutungen? Ansonsten muss ich das erstmal auf Eis legen.
Veit D. schrieb: > Hallo, > > eine Neuinstallation der Software unter Linux die man zum bauen benötigt > brachte auch keinen Erfolg. Irgendwelche anderen Vermutungen? Ansonsten > muss ich das erstmal auf Eis legen. Sorry, ich sehe das leider nicht. Da müsste ich selbst dran rumfrickeln, um den Fehler vllt. zu finden.
Hallo, unter Ubuntu benötige ich nur das was unter 12:41 Uhr aufgelistet ist. Hilft es dir wenn ich dir meine Bau Scripte gebe?
Mach die Schritte doch mal einzeln, dann sieht du auch was schief geht. Anstatt in einem Skript, das durchrauscht, egal was passiert.
Hallo, die Windows Bauphase ist schon in 3 Abschnitte unterteilt. Sind alle im .zip. Wenn es mit der Bauphase der binutils zusammenhängt, dann sollte in dessen Terminallogfile bzw. Config.log etwas zu finden sein. Wonach genau würdest du in den Files schauen? Mir fehlt da die Erfahrung. Was hat es mit den uint Warnungen auf sich? Zur Zeit teste ich das Script von Zakkemble. Mal sehen ob das durchläuft und wie sich das mit den binutils Versionen verhält. Ich werde meine Scripte anschließend nochmal mit verschiedenen set Optionen laufen lassen. Nur weiß ich schon das es mit -e bei den uint Warnungen abbricht. Weit werde ich damit nicht kommen.
Hallo, das Script von Zakkemble läuft leider auch nicht durch. Je nach binutils Version mal ziemlich weit bzw. kurz. "2.37" bricht zeitig hier ab siehe unten. Morgen mach ich mit meinen Scripten weiter ... Ich glaube aber nicht daran das es an den Scripten liegt, sondern das dem Ubuntu irgendein Tool oder Datei fehlt. So meine Vermutung. Letztens fehlte texinfo die eine damals neue Version von binutils plötzlich verlangte. Was habt ihr zum bauen alles für Tools/Software installiert?
1 | checking whether stpcpy is declared... no |
2 | checking whether asprintf is declared... yes |
3 | checking whether vasprintf is declared... make[2]: Leaving directory '/home/ubuntixer/zakkemble/binutils-2.37/obj-avr/libiberty' |
4 | make[1]: *** [Makefile:8152: all-libiberty] Error 2 |
5 | make[1]: *** Waiting for unfinished jobs.... |
6 | yes |
7 | checking whether strnlen is declared... yes |
8 | checking compiler support for hidden visibility... no |
9 | checking linker --as-needed support... yes |
10 | checking for cos in -lm... yes |
11 | checking for gcc version with buggy 64-bit support... no |
12 | checking for ftello... yes |
13 | checking for ftello64... yes |
14 | checking for fseeko... yes |
15 | checking for fseeko64... yes |
16 | checking for fopen64... yes |
17 | checking whether ftello is declared... yes |
18 | checking whether ftello64 is declared... yes |
19 | checking whether fseeko is declared... yes |
20 | checking whether fseeko64 is declared... yes |
21 | checking whether fopen64 is declared... yes |
22 | checking size of off_t... config.status: executing libtool commands |
23 | config.status: executing default-1 commands |
24 | config.status: executing default commands |
25 | 8 |
26 | checking file_ptr type... BFD_HOST_64_BIT |
27 | checking for stdlib.h... (cached) yes |
28 | checking for unistd.h... (cached) yes |
29 | checking for sys/param.h... yes |
30 | checking for getpagesize... (cached) yes |
31 | checking for working mmap... no |
32 | checking for madvise... no |
33 | checking for mprotect... yes |
34 | configure: updating cache ./config.cache |
35 | checking that generated files are newer than configure... done |
36 | configure: creating ./config.status |
37 | config.status: creating Makefile |
38 | config.status: creating doc/Makefile |
39 | config.status: creating bfd-in3.h |
40 | config.status: creating po/Makefile.in |
41 | config.status: creating config.h |
42 | config.status: executing depfiles commands |
43 | config.status: executing libtool commands |
44 | config.status: executing default-1 commands |
45 | config.status: executing default commands |
46 | make[1]: Leaving directory '/home/ubuntixer/zakkemble/binutils-2.37/obj-avr' |
47 | make: *** [Makefile:915: all] Error 2 |
Hallo, wenn ich das Windows Build binutils Schritt für Schritt mache bekomme ich mit 'make' schon Fehlermeldungen. Hier weiß ich nicht wie gravierend die sind. Und wenn ich weitermache mit 'make install' fehlt ihm ein zlib Verzeichnis und bricht ab. Fehlt eine Software zum bauen?
Veit D. schrieb: > wenn ich das Windows Build binutils Schritt für Schritt mache bekomme > ich mit 'make' schon Fehlermeldungen. Hier weiß ich nicht wie gravierend > die sind. Nun ja, diese hier wurde oben ja schon erwähnt: error: unknown type name ‘uint’ 78 | uint recursion; Wie gravieren sowas ist, kannst du dir selber ja zusammenreimen. Ich würde sagen, schon ein kleines bisschen…. Oliver
Frag doch mal in der Binutils Mailing-Liste.
Hallo, hatte heute noch eine neue Umgebung mit Ubuntu 21.04 statt 20.04.LTS eingerichtet in der Hoffnung das irgendein benötigtes Softwarepaket vielleicht veraltet ist. War aber nicht der Fall. Die Arbeit war umsonst. Das installieren von zlib brachte auch keinen Erfolg. wegen error: unknown type name ‘uint’ Wenn ich in Zeile 81 in der rust-demangle.c 'uint' gegen 'unsigned' austausche kompiliert gar nichts mehr. Da will schon das Linux Build Script gleich zu Anfang nicht laufen. Wäre interessant was Al Fine da genau geändert hat? Werde wohl doch einmal in der Mailing Liste fragen. Danke erstmal an alle für eure Zeit und Mühe fürs mitmachen.
Veit D. schrieb: > Wäre interessant was Al Fine da Ich habe in der Datei alle Vorkommen von uint gegen unsigned ausgetauscht. War keine Rocket-Science.
LiberNicht schrieb: > Veit D. schrieb: >> Wäre interessant was Al Fine da > Ach- PS: Schreib das echt ruhig mal an die Mailing-Liste.
Hallo, an die Mailing Liste habe ich soeben geschrieben. Hoffe das das auch ankommt und ich auch benachrichtigt werde. Auf die Mailingliste setzen konnte ich mich nicht, erhalte immer Server Error. > Ich habe in der Datei alle Vorkommen von uint gegen unsigned > ausgetauscht. War keine Rocket-Science. Also an genau 2 Stellen?
Hallo, ich habe jetzt mal mehr oder weniger Spaßenshalber die rust-demangle.c gegen die Datei aus binutils 2.36.1 ausgetauscht. Die Toolchain scheint vollständig zu sein. Die hier Beitrag "Re: mal wieder binutils, diesmal v2.37 (avr-gcc)" als fehlend aufgeführten Ordner sind vorhanden. Jetzt vervollständige ich noch fehlende Controller Dateien und teste das einmal in AS7. Zur Zeit baut es erneut mit 'unsigned' Korrektur.
Hallo, also die vorhin gebaute Toolchain funktioniert erstmal. Mit verschiedenen Controllern Code kompilieren und ein Blinktest geflasht > funktioniert. Da scheint wirklich die rust-demangle.c irgendwie schuldig zu sein. Hätte ich so nicht gedacht. Das neue Build mit 'uint -> unsigned' läuft noch ...
Hallo, also :-) , die neue Toolchain mit der 'unsigned' modifizierten rust-demangle.c ist auch vollständig und funktioniert in AS7. Die Datei rust-demangle.c wurde grob gesagt um paar Zeilen ergänzt u.a. mit dem ominösen uint ergänzt. Sehr große Unterschiede gibts nicht zwischen v2.36.1 und 2.37. Entweder ändert man uint zu unsigned oder tauscht diese Datei mit der aus den binutils 2.36.1 aus. Beides funktioniert(e) bei mir. Ich hätte nie gedacht das diese eine Warnung soviel Auswirklung hat, denn Warnungen gibts ja mehrere während des Bauprozesses. Zudem es die Vorsilbe uint ja in C/C++ gibt. Deswegen hatte ich das nicht weiterverfolgt. Ganz großes Danke an alle für die Hilfe und Hinweise. Was für ein Wahnsinn. :-) Soll ich meine E-Mail mit den Erkenntnissen ergänzen und nochmal an die Mailingliste senden?
Veit D. schrieb: > Ich hätte nie gedacht das diese eine Warnung soviel Auswirklung hat, Warnungen gibts zwar viele, aber das war keine. Das war ein Fehler, englisch: error. Den Unterschied müsstest du nochmals nachlesen. Oliver
Oliver S. schrieb: > Veit D. schrieb: >> Ich hätte nie gedacht das diese eine Warnung soviel Auswirklung hat, > > Warnungen gibts zwar viele, aber das war keine. Das war ein Fehler, > englisch: error. Den Unterschied müsstest du nochmals nachlesen. > > Oliver Richtig. Ich würde empfehlen, in solchen Build-Skripten mit "set -e" zu arbeiten. Dann hält das Skript beim ersten Fehler an, anstatt einfach beim nächsten Kommando weiter zu machen.
Hallo, stimmt, war ein Fehler und keine Warnung. -e hatte ich vor langer Zeit aus irgendwelchen Gründen rausgenommen. Werde ich wieder reinmachen.
Welche neuen Features der Binutils brauchst du denn, so dass die v2.36 nicht gut genug ist?
Hallo, derzeit nichts dringendes. Hatte nur gesehen das gcc 11.2. raus ist und habe mir eine neue Toolchain bauen wollen. Zum Zeitpunkt verwende ich dann immer von allen die aktuellen Versionen. Nur deswegen bin ich darüber gestolpert. Übrigens wurde das Problem mit der binutils 2.37 im "branch with commit 999566402e3" gefixt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.