mal wieder binutils, diesmal v2.37 (avr-gcc)

Du verwendest wohl die Host-Tools, und die kennen natürlich keine 
AVR-Optionen.

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?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.