Toochain bauen avr-gcc-x.x mit binutils-2.34 funktioniert nicht

[Veit D. (devil-elec)]

Hallo,

ich wollte eine neue Toolchain mit gcc 9.3 bauen. Dieses gleich mit den 
aktuellen binutils 2.34. Allerdings klappt das nicht. Siehe 
Dateianhängen.
Habe folgendes über Kreuz getestet.
gcc 9.3 mit binutils 2.34 > nicht okay
gcc 9.3 mit binutils 2.32 > okay
gcc 9.2 mit binutils 2.32 > okay
gcc 9.2 mit binutils 2.34 > nicht okay
gcc 9.2 mit binutils 2.33.1 > okay
gcc 9.3 mit binutils 2.33.1 > okay

Daraus schließe ich das mit den binutils 2.34 etwas nicht stimmt.
Aus der Doku kann ich auch nichts entnehmen das sich etwas in den 
Optionen geändert haben könnte.
Gebaut wird mittels Ubuntu 18.04.4 LTS.

Wenn man in der Konsolenausgabe etwas hochscrollt liest man diesen 
ersten Fehler.

Makefile:12901: recipe for target 'install-strip-target-libgcc' failed
make[1]: *** [install-strip-target-libgcc] Error 2
make[1]: Verzeichnis „/home/ubuntixer/toolchain/buildLinux/gcc“ wird 
verlassen
Makefile:2475: recipe for target 'install-strip' failed
make: *** [install-strip] Error 2

Kann mir jemand sagen wo es genau klemmt?

[Veit D. (devil-elec)]

Hallo,

habe dann mal mit gcc10 probiert.

gcc10 will mit binutils 2.34 und 2.33.1 auch nicht. v2.32 ist nicht 
getestet. Bin dann die Konsolenausgabe nochmal durch, weil diesmal 
zwischendrin was rotes aufblitzte und habe 'flex' nachinstalliert.

Bleibt am Ende aber auch wieder mit 'install-strip' Fehler stehen.

Bin ratlos.

(Logfile vom binutils Ordner gibts nicht)

[Veit D. (devil-elec)]

Hallo,

laut meiner Meinung gibts ein Problem mit der -strip Option.

Entferne ich die Option im Script für binutils, kann ich eine Toolchain 
aus gcc10 und binutils 2.33.1 bauen. Das Endergebnis ist dann leider ca. 
doppelt so groß. Die Kombination gcc10 und binutils 2.34 gelingt aucn 
nicht nach dem entfernen der -strip Option zusätzlich für die avr-libs.

Hat jemand einen Tipp?

[Veit D. (devil-elec)]

Hallo,

habe noch die Kombination gcc-10.0.1 mit binutils-2.32 getestet. Das 
kompiliert alles wie soll mit make install-strip.

Damit ist eigentlich der Beweisführung zu Genüge getan das in den 
Neueren binutils irgendein Fehler steckt.

Meine Frage wäre, ist das schon bekannt? Wird daran schon gearbeitet?

[Jörg W. (dl8dtl) (Moderator)]

as: unrecognized option '-mmcu=avr2'

Wobei mir gerade nicht ganz klar ist, ob das nun passiert, weil die 
Binutils kein "avr2" unterstützen, oder ob aus Versehen der Assembler 
des Hosts statt des Targets aufgerufen wird. Das sollte dir die Ausgabe 
eines "strace" sagen können.

[foobar (Gast)]

Der Build hat doch schon viel früher Probleme, das Script ignoriert die 
aber und macht einfach weiter.  Setzt mal zum -x auch noch -e.

[Veit D. (devil-elec)]

Hallo,

das strace Logfile mit Option -f ist 5GByte groß.
Habs ohne -f und mit set -e wiederholt.

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:
> Habs ohne -f und mit set -e wiederholt.

Das bringt nichts.

Du musst es mit -f laufen lassen, und dich schon mal selbst durchwühlen 
um rauszufinden, welchen Assembler er da aufruft. Suche nach "/as" 
sollte gar nicht so viele Treffer haben, kannst ja von hinten rückwärts 
suchen.

[Veit D. (devil-elec)]

Hallo,

ich versuche das einmal ...

Wenn ich das richtig überblicke gehts in der Konsolenausgabe schon in 
Zeile 3558 los beim betreten von 
„/home/ubuntixer/toolchain/buildLinux/gcc/avr/libgcc“

[Veit D. (devil-elec)]

Hallo,

habs mit
> grep -C 2 "/as" xxx.log >> xxx.txt
gefiltert, ergibt 57MB, gepackt 3,2MB. Ich glaube das kann ich Euch 
zumuten.

https://www.dropbox.com/s/3vnhlamqpnaj1rl/Konsolenlog_2Zeilen.zip?dl=0

Ich kann mit dem Inhalt nichts anfangen, außer das ich sehe das immer 
"No such file or directory" ausgegeben wird.

[Jörg W. (dl8dtl) (Moderator)]

Hast du denn mal versucht, darin nach dem String "/as" zu suchen?

Ich vermute nämlich, dass er "/usr/bin/as" benutzt, obwohl er 
"<...>/avr/bin/as" benutzen sollte. Wenn dem so ist, dann wäre es kein 
Wunder, dass /usr/bin/as kein -mmcu=avr2 mag. Sollte er wirklich den 
AVR-Assembler rufen, und der beklagt sich darüber, dann hieße das, dass 
in den aktuellen Binutils irgendwas daneben ist und (mindestens) avr2 
nicht mehr unterstützt ist.

[A. B. (Gast)]

Die letzten 28 Zeilen der Datei KonsolenLog2.txt
************************************************

execve("/usr/local/sbin/as", ["as", "-mmcu=avr2", "-o", "/t ...
________^^^^^^^^^^^^^^^^^^

[Veit D. (devil-elec)]

Hallo,

das "/as" Filterergebnis steht in dem gepackten Logfile.
Das sind die ersten Zeilen in notepad++ gefiltert. Sind 168617 Treffer.
Heute Abend kann ich weiter machen.

21516 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21516 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21516 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21516 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21516 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21516 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21516 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21516 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/as", 0x7fff9c89eb40) = -1 ENOENT (No such file or directory)
21518 execve("/usr/local/sbin/as", ["as", "--64", "-o", "/tmp/cgXDQVBx/dummy.o", "/tmp/cc3NvgZl.s"], 0x267ad40 /* 72 vars */) = -1 ENOENT (No such file or directory)
21518 execve("/usr/local/bin/as", ["as", "--64", "-o", "/tmp/cgXDQVBx/dummy.o", "/tmp/cc3NvgZl.s"], 0x267ad40 /* 72 vars */) = -1 ENOENT (No such file or directory)
21518 execve("/usr/sbin/as", ["as", "--64", "-o", "/tmp/cgXDQVBx/dummy.o", "/tmp/cc3NvgZl.s"], 0x267ad40 /* 72 vars */) = -1 ENOENT (No such file or directory)
21518 execve("/usr/bin/as", ["as", "--64", "-o", "/tmp/cgXDQVBx/dummy.o", "/tmp/cc3NvgZl.s"], 0x267ad40 /* 72 vars */ <unfinished ...>
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21584 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/as", 0x7fff499ab8e0) = -1 ENOENT (No such file or directory)
21586 execve("/usr/local/sbin/as", ["as", "--64", "-o", "/tmp/ccaMmAdJ.o", "/tmp/ccLV76vG.s"], 0xcf9980 /* 73 vars */) = -1 ENOENT (No such file or directory)
21586 execve("/usr/local/bin/as", ["as", "--64", "-o", "/tmp/ccaMmAdJ.o", "/tmp/ccLV76vG.s"], 0xcf9980 /* 73 vars */) = -1 ENOENT (No such file or directory)
21586 execve("/usr/sbin/as", ["as", "--64", "-o", "/tmp/ccaMmAdJ.o", "/tmp/ccLV76vG.s"], 0xcf9980 /* 73 vars */) = -1 ENOENT (No such file or directory)
21586 execve("/usr/bin/as", ["as", "--64", "-o", "/tmp/ccaMmAdJ.o", "/tmp/ccLV76vG.s"], 0xcf9980 /* 73 vars */ <unfinished ...>
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21591 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/as", 0x7ffe24806f40) = -1 ENOENT (No such file or directory)
21593 execve("/usr/local/sbin/as", ["as", "--64", "-o", "/tmp/ccP9GNba.o", "/tmp/cc85Za45.s"], 0xb0cb60 /* 73 vars */) = -1 ENOENT (No such file or directory)
21593 execve("/usr/local/bin/as", ["as", "--64", "-o", "/tmp/ccP9GNba.o", "/tmp/cc85Za45.s"], 0xb0cb60 /* 73 vars */) = -1 ENOENT (No such file or directory)
21593 execve("/usr/sbin/as", ["as", "--64", "-o", "/tmp/ccP9GNba.o", "/tmp/cc85Za45.s"], 0xb0cb60 /* 73 vars */) = -1 ENOENT (No such file or directory)
21593 execve("/usr/bin/as", ["as", "--64", "-o", "/tmp/ccP9GNba.o", "/tmp/cc85Za45.s"], 0xb0cb60 /* 73 vars */ <unfinished ...>
21600 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd885dcac0) = -1 ENOENT (No such file or directory)
21600 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd885dcac0) = -1 ENOENT (No such file or directory)
21600 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd885dcac0) = -1 ENOENT (No such file or directory)
21600 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd885dcac0) = -1 ENOENT (No such file or directory)
21600 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd885dcac0) = -1 ENOENT (No such file or directory)
21600 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as", 0x7ffd885dcac0) = -1 ENOENT (No such file or directory)

[Veit D. (devil-elec)]

Hallo,

soll ich nochmal was speziell filtern?
Oder sind die Informationen ausreichend?
Oder was könnte ich noch machen?

[Jörg W. (dl8dtl) (Moderator)]

Habe gerade mal die binutils-2.34 für AVR gebaut:

% ./gas/as-new --help
Usage: ./gas/as-new [option...] [asmfile...]
Options:
  -a[sub-option...]       turn on listings
                          Sub-options [default hls]:
                          c      omit false conditionals
                          d      omit debugging directives
                          g      include general info
                          h      include high-level source
                          l      include assembly
                          m      include macro expansions
                          n      omit forms processing
                          s      include symbols
                          =FILE  list to FILE (must be last sub-option)
  --alternate             initially turn on alternate macro syntax
  --compress-debug-sections[={none|zlib|zlib-gnu|zlib-gabi}]
                          compress DWARF debug sections using zlib
  --nocompress-debug-sections
                          don't compress DWARF debug sections [default]
  -D                      produce assembler debugging messages
  --debug-prefix-map OLD=NEW
                          map OLD to NEW in debug information
  --defsym SYM=VAL        define symbol SYM to given value
  --execstack             require executable stack for this object
  --noexecstack           don't require executable stack for this object
  --size-check=[error|warning]
                          ELF .size directive check (default --size-check=error)
  --elf-stt-common=[no|yes] (default: no)
                          generate ELF common symbols with STT_COMMON type
  --sectname-subst        enable section name substitution sequences
  --generate-missing-build-notes=[no|yes] (default: no)
                          generate GNU Build notes if none are present in the input
  -f                      skip whitespace and comment preprocessing
  -g --gen-debug          generate debugging information
  --gstabs                generate STABS debugging information
  --gstabs+               generate STABS debug info with GNU extensions
  --gdwarf-2              generate DWARF2 debugging information
  --gdwarf-sections       generate per-function section names for DWARF line information
  --hash-size=<value>     set the hash table size close to <value>
  --help                  show this message and exit
  --target-help           show target specific options
  -I DIR                  add DIR to search list for .include directives
  -J                      don't warn about signed overflow
  -K                      warn when differences altered for long displacements
  -L,--keep-locals        keep local symbols (e.g. starting with `L')
  -M,--mri                assemble in MRI compatibility mode
  --MD FILE               write dependency information in FILE (default none)
  -nocpp                  ignored
  -no-pad-sections        do not pad the end of sections to alignment boundaries
  -o OBJFILE              name the object-file output OBJFILE (default a.out)
  -R                      fold data section into text section
  --reduce-memory-overheads 
                          prefer smaller memory use at the cost of longer
                          assembly times
  --statistics            print various measured statistics from execution
  --strip-local-absolute  strip local absolute symbols
  --traditional-format    Use same format as native assembler when possible
  --version               print assembler version number and exit
  -W  --no-warn           suppress warnings
  --warn                  don't suppress warnings
  --fatal-warnings        treat warnings as errors
  -w                      ignored
  -X                      ignored
  -Z                      generate object file even after errors
  --listing-lhs-width     set the width in words of the output data column of
                          the listing
  --listing-lhs-width2    set the width in words of the continuation lines
                          of the output data column; ignored if smaller than
                          the width of the first line
  --listing-rhs-width     set the max width in characters of the lines from
                          the source file
  --listing-cont-lines    set the maximum number of continuation lines used
                          for the output data column of the listing
  @FILE                   read options from FILE
AVR Assembler options:
  -mmcu=[avr-name] select microcontroller variant
                   [avr-name] can be:
                   avr1  - classic AVR core without data RAM
                   avr2  - classic AVR core with up to 8K program memory
                   avr25 - classic AVR core with up to 8K program memory
                           plus the MOVW instruction
                   avr3  - classic AVR core with up to 64K program memory
                   avr31 - classic AVR core with up to 128K program memory
                   avr35 - classic AVR core with up to 64K program memory
                           plus the MOVW instruction
                   avr4  - enhanced AVR core with up to 8K program memory
                   avr5  - enhanced AVR core with up to 64K program memory
                   avr51 - enhanced AVR core with up to 128K program memory
                   avr6  - enhanced AVR core with up to 256K program memory
                   avrxmega2 - XMEGA, > 8K, < 64K FLASH, < 64K RAM
                   avrxmega3 - XMEGA, RAM + FLASH < 64K, Flash visible in RAM
                   avrxmega4 - XMEGA, > 64K, <= 128K FLASH, <= 64K RAM
                   avrxmega5 - XMEGA, > 64K, <= 128K FLASH, > 64K RAM
                   avrxmega6 - XMEGA, > 128K, <= 256K FLASH, <= 64K RAM
                   avrxmega7 - XMEGA, > 128K, <= 256K FLASH, > 64K RAM
                   avrtiny   - AVR Tiny core with 16 gp registers
  -mall-opcodes    accept all AVR opcodes, even if not supported by MCU
  -mno-skip-bug    disable warnings for skipping two-word instructions
                   (default for avr4, avr5)
  -mno-wrap        reject rjmp/rcall instructions with 8K wrap-around
                   (default for avr3, avr5)
  -mrmw            accept Read-Modify-Write instructions
  -mlink-relax     generate relocations for linker relaxation (default)
  -mno-link-relax  don't generate relocations for linker relaxation.
  -mgcc-isr        accept the __gcc_isr pseudo-instruction.
Known MCU names:
  avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1
  avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny
  at90s1200 attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323
  at90s2333 at90s2343 attiny22 attiny26 at90s4414 at90s4433 at90s4434
  at90s8515 at90c8534 at90s8535 ata5272 attiny13 attiny13a attiny2313
  attiny2313a attiny24 attiny24a attiny4313 attiny44 attiny44a attiny84
  attiny84a attiny25 attiny45 attiny85 attiny261 attiny261a attiny461
  attiny461a attiny861 attiny861a attiny87 attiny43u attiny48 attiny88
  attiny828 at86rf401 at43usb355 at76c711 atmega103 at43usb320 attiny167
  at90usb82 at90usb162 ata5505 atmega8u2 atmega16u2 atmega32u2 attiny1634
  atmega8 ata6289 atmega8a ata6285 ata6286 atmega48 atmega48a atmega48pa
  atmega48p atmega88 atmega88a atmega88p atmega88pa atmega8515 atmega8535
  atmega8hva at90pwm1 at90pwm2 at90pwm2b at90pwm3 at90pwm3b at90pwm81
  at90pwm161 ata5790 ata5795 atmega16 atmega16a atmega161 atmega162
  atmega163 atmega164a atmega164p atmega164pa atmega165 atmega165a
  atmega165p atmega165pa atmega168 atmega168a atmega168p atmega168pa
  atmega169 atmega169a atmega169p atmega169pa atmega32 atmega32a atmega323
  atmega324a atmega324p atmega324pa atmega325 atmega325a atmega325p
  atmega325pa atmega3250 atmega3250a atmega3250p atmega3250pa atmega328
  atmega328p atmega329 atmega329a atmega329p atmega329pa atmega3290
  atmega3290a atmega3290p atmega3290pa atmega406 atmega64rfr2
  atmega644rfr2 atmega64 atmega64a atmega640 atmega644 atmega644a
  atmega644p atmega644pa atmega645 atmega645a atmega645p atmega649
  atmega649a atmega649p atmega6450 atmega6450a atmega6450p atmega6490
  atmega6490a atmega6490p atmega64rfr2 atmega644rfr2 atmega16hva
  atmega16hva2 atmega16hvb atmega16hvbrevb atmega32hvb atmega32hvbrevb
  atmega64hve at90can32 at90can64 at90pwm161 at90pwm216 at90pwm316
  atmega32c1 atmega64c1 atmega16m1 atmega32m1 atmega64m1 atmega16u4
  atmega32u4 atmega32u6 at90usb646 at90usb647 at90scr100 at94k m3000
  atmega128 atmega128a atmega1280 atmega1281 atmega1284 atmega1284p
  atmega128rfa1 atmega128rfr2 atmega1284rfr2 at90can128 at90usb1286
  at90usb1287 atmega2560 atmega2561 atmega256rfr2 atmega2564rfr2
  atxmega16a4 atxmega16a4u atxmega16c4 atxmega16d4 atxmega32a4
  atxmega32a4u atxmega32c4 atxmega32d4 atxmega32e5 atxmega16e5 atxmega8e5
  atxmega32x1 attiny212 attiny214 attiny412 attiny414 attiny416 attiny417
  attiny814 attiny816 attiny817 attiny1614 attiny1616 attiny1617
  attiny3214 attiny3216 attiny3217 atxmega64a3 atxmega64a3u atxmega64a4u
  atxmega64b1 atxmega64b3 atxmega64c3 atxmega64d3 atxmega64d4 atxmega64a1
  atxmega64a1u atxmega128a3 atxmega128a3u atxmega128b1 atxmega128b3
  atxmega128c3 atxmega128d3 atxmega128d4 atxmega192a3 atxmega192a3u
  atxmega192c3 atxmega192d3 atxmega256a3 atxmega256a3u atxmega256a3b
  atxmega256a3bu atxmega256c3 atxmega256d3 atxmega384c3 atxmega384d3
  atxmega128a1 atxmega128a1u atxmega128a4u attiny4 attiny5 attiny9
  attiny10 attiny20 attiny40

Report bugs to <http://www.sourceware.org/bugzilla/>

"avr2" ist also definitiv noch in der Liste. Damit ist klar, dass der 
GCC bei dir irgendwie den falschen Assembler aufruft.

Schau mal, ob dein $PATH korrekt ist und der installierte AVR-Assembler 
gestartet wird, wenn du ihn "avr-as" nennst. Es kann auch helfen, dass 
${prefix}/bin vor den Systempfaden in $PATH liegt.

[Veit D. (devil-elec)]

Hallo,

ich habe gerade tausende Fragezeichen was ich machen soll.
Mir stellt sich immer noch die Frage warum das mit v2.32 funktioniert 
und mit neuere Versionen nicht.
Mal sehen was ich mit "avr-as" anfangen kann ...

[Veit D. (devil-elec)]

Hallo,

einen installierten avr habe ich nicht.
Wenn ich dem "bauen" zuschaue, dann macht er was mit den avr-libc.
+ cd /home/ubuntixer/toolchain/downloads/avr-libc

Nachdem alle avr Verzeichnisse erstellt sind, findet er ./config.guess 
nicht, host avr ist unknown und dann ist Ende

checking for suffix of object files... configure: error: in 
`/home/ubuntixer/toolchain/buildLinux/avr-libc':
configure: error: cannot compute suffix of object files: cannot compile

+ cd /home/ubuntixer/toolchain/downloads/avr-libc
+ ./bootstrap
+ rm -rf avr/lib
+ ./devtools/gen-avr-lib-tree.sh
Generating source directories:
  avr/lib/avr2/
  avr/lib/avr2/at90s1200
  avr/lib/avr2/attiny11
  avr/lib/avr2/attiny12
  avr/lib/avr2/attiny15
  avr/lib/avr2/attiny28
  avr/lib/avr2/at90s4414
  avr/lib/avr2/at90s4434
  avr/lib/avr2/at90s8515
  avr/lib/avr2/at90s8535
  avr/lib/avr2/at90c8534
  avr/lib/avr2/tiny-stack/
  avr/lib/avr2/tiny-stack/at90s2313
  avr/lib/avr2/tiny-stack/at90s2323
  avr/lib/avr2/tiny-stack/at90s2333
  avr/lib/avr2/tiny-stack/at90s2343
  avr/lib/avr2/tiny-stack/at90s4433
  avr/lib/avr2/tiny-stack/attiny22
  avr/lib/avr2/tiny-stack/attiny26
  avr/lib/avr25/
  avr/lib/avr25/at86rf401
  avr/lib/avr25/ata5272
  avr/lib/avr25/ata6616c
  avr/lib/avr25/attiny4313
  avr/lib/avr25/attiny43u
  avr/lib/avr25/attiny44
  avr/lib/avr25/attiny44a
  avr/lib/avr25/attiny441
  avr/lib/avr25/attiny45
  avr/lib/avr25/attiny461
  avr/lib/avr25/attiny461a
  avr/lib/avr25/attiny48
  avr/lib/avr25/attiny828
  avr/lib/avr25/attiny84
  avr/lib/avr25/attiny84a
  avr/lib/avr25/attiny841
  avr/lib/avr25/attiny85
  avr/lib/avr25/attiny861
  avr/lib/avr25/attiny861a
  avr/lib/avr25/attiny87
  avr/lib/avr25/attiny88
  avr/lib/avr25/tiny-stack/
  avr/lib/avr25/tiny-stack/attiny13
  avr/lib/avr25/tiny-stack/attiny13a
  avr/lib/avr25/tiny-stack/attiny2313
  avr/lib/avr25/tiny-stack/attiny2313a
  avr/lib/avr25/tiny-stack/attiny24
  avr/lib/avr25/tiny-stack/attiny24a
  avr/lib/avr25/tiny-stack/attiny25
  avr/lib/avr25/tiny-stack/attiny261
  avr/lib/avr25/tiny-stack/attiny261a
  avr/lib/avr3/
  avr/lib/avr3/at43usb355
  avr/lib/avr3/at76c711
  avr/lib/avr31/
  avr/lib/avr31/atmega103
  avr/lib/avr31/at43usb320
  avr/lib/avr35/
  avr/lib/avr35/at90usb82
  avr/lib/avr35/at90usb162
  avr/lib/avr35/ata5505
  avr/lib/avr35/ata6617c
  avr/lib/avr35/ata664251
  avr/lib/avr35/atmega8u2
  avr/lib/avr35/atmega16u2
  avr/lib/avr35/atmega32u2
  avr/lib/avr35/attiny167
  avr/lib/avr35/attiny1634
  avr/lib/avr4/
  avr/lib/avr4/ata6285
  avr/lib/avr4/ata6286
  avr/lib/avr4/ata6289
  avr/lib/avr4/ata6612c
  avr/lib/avr4/atmega48
  avr/lib/avr4/atmega48a
  avr/lib/avr4/atmega48pa
  avr/lib/avr4/atmega48pb
  avr/lib/avr4/atmega48p
  avr/lib/avr4/atmega8
  avr/lib/avr4/atmega8a
  avr/lib/avr4/atmega88
  avr/lib/avr4/atmega88a
  avr/lib/avr4/atmega88p
  avr/lib/avr4/atmega88pa
  avr/lib/avr4/atmega88pb
  avr/lib/avr4/atmega8515
  avr/lib/avr4/atmega8535
  avr/lib/avr4/atmega8hva
  avr/lib/avr4/at90pwm1
  avr/lib/avr4/at90pwm2
  avr/lib/avr4/at90pwm2b
  avr/lib/avr4/at90pwm3
  avr/lib/avr4/at90pwm3b
  avr/lib/avr4/at90pwm81
  avr/lib/avr5/
  avr/lib/avr5/at90can32
  avr/lib/avr5/at90can64
  avr/lib/avr5/at90pwm216
  avr/lib/avr5/at90pwm316
  avr/lib/avr5/at90pwm161
  avr/lib/avr5/at90scr100
  avr/lib/avr5/at90usb646
  avr/lib/avr5/at90usb647
  avr/lib/avr5/at94k
  avr/lib/avr5/ata5702m322
  avr/lib/avr5/ata5782
  avr/lib/avr5/ata5790
  avr/lib/avr5/ata5790n
  avr/lib/avr5/ata5795
  avr/lib/avr5/ata5831
  avr/lib/avr5/ata6613c
  avr/lib/avr5/ata6614q
  avr/lib/avr5/atmega16
  avr/lib/avr5/atmega16a
  avr/lib/avr5/atmega161
  avr/lib/avr5/atmega162
  avr/lib/avr5/atmega163
  avr/lib/avr5/atmega164a
  avr/lib/avr5/atmega164p
  avr/lib/avr5/atmega164pa
  avr/lib/avr5/atmega165
  avr/lib/avr5/atmega165a
  avr/lib/avr5/atmega165p
  avr/lib/avr5/atmega165pa
  avr/lib/avr5/atmega168
  avr/lib/avr5/atmega168a
  avr/lib/avr5/atmega168p
  avr/lib/avr5/atmega168pa
  avr/lib/avr5/atmega169
  avr/lib/avr5/atmega169a
  avr/lib/avr5/atmega169p
  avr/lib/avr5/atmega169pa
  avr/lib/avr5/atmega16hva
  avr/lib/avr5/atmega16hva2
  avr/lib/avr5/atmega16hvb
  avr/lib/avr5/atmega16hvbrevb
  avr/lib/avr5/atmega16m1
  avr/lib/avr5/atmega16u4
  avr/lib/avr5/atmega32
  avr/lib/avr5/atmega32a
  avr/lib/avr5/atmega323
  avr/lib/avr5/atmega324a
  avr/lib/avr5/atmega324p
  avr/lib/avr5/atmega324pa
  avr/lib/avr5/atmega325
  avr/lib/avr5/atmega325a
  avr/lib/avr5/atmega325p
  avr/lib/avr5/atmega325pa
  avr/lib/avr5/atmega3250
  avr/lib/avr5/atmega3250a
  avr/lib/avr5/atmega3250p
  avr/lib/avr5/atmega3250pa
  avr/lib/avr5/atmega328
  avr/lib/avr5/atmega328p
  avr/lib/avr5/atmega329
  avr/lib/avr5/atmega329a
  avr/lib/avr5/atmega329p
  avr/lib/avr5/atmega329pa
  avr/lib/avr5/atmega3290
  avr/lib/avr5/atmega3290a
  avr/lib/avr5/atmega3290p
  avr/lib/avr5/atmega3290pa
  avr/lib/avr5/atmega32c1
  avr/lib/avr5/atmega32hvb
  avr/lib/avr5/atmega32hvbrevb
  avr/lib/avr5/atmega32m1
  avr/lib/avr5/atmega32u4
  avr/lib/avr5/atmega32u6
  avr/lib/avr5/atmega406
  avr/lib/avr5/atmega644rfr2
  avr/lib/avr5/atmega64rfr2
  avr/lib/avr5/atmega64
  avr/lib/avr5/atmega64a
  avr/lib/avr5/atmega640
  avr/lib/avr5/atmega644
  avr/lib/avr5/atmega644a
  avr/lib/avr5/atmega644p
  avr/lib/avr5/atmega644pa
  avr/lib/avr5/atmega645
  avr/lib/avr5/atmega645a
  avr/lib/avr5/atmega645p
  avr/lib/avr5/atmega6450
  avr/lib/avr5/atmega6450a
  avr/lib/avr5/atmega6450p
  avr/lib/avr5/atmega649
  avr/lib/avr5/atmega649a
  avr/lib/avr5/atmega649p
  avr/lib/avr5/atmega6490
  avr/lib/avr5/atmega6490a
  avr/lib/avr5/atmega6490p
  avr/lib/avr5/atmega64c1
  avr/lib/avr5/atmega64hve
  avr/lib/avr5/atmega64hve2
  avr/lib/avr5/atmega64m1
  avr/lib/avr5/m3000
  avr/lib/avr51/
  avr/lib/avr51/atmega128
  avr/lib/avr51/atmega128a
  avr/lib/avr51/atmega1280
  avr/lib/avr51/atmega1281
  avr/lib/avr51/atmega1284
  avr/lib/avr51/atmega1284p
  avr/lib/avr51/atmega128rfa1
  avr/lib/avr51/atmega1284rfr2
  avr/lib/avr51/atmega128rfr2
  avr/lib/avr51/at90can128
  avr/lib/avr51/at90usb1286
  avr/lib/avr51/at90usb1287
  avr/lib/avr6/
  avr/lib/avr6/atmega2560
  avr/lib/avr6/atmega2561
  avr/lib/avr6/atmega2564rfr2
  avr/lib/avr6/atmega256rfr2
  avr/lib/avrxmega2/
  avr/lib/avrxmega2/atxmega8e5
  avr/lib/avrxmega2/atxmega16a4
  avr/lib/avrxmega2/atxmega16a4u
  avr/lib/avrxmega2/atxmega16c4
  avr/lib/avrxmega2/atxmega16d4
  avr/lib/avrxmega2/atxmega32a4
  avr/lib/avrxmega2/atxmega32a4u
  avr/lib/avrxmega2/atxmega32c3
  avr/lib/avrxmega2/atxmega32c4
  avr/lib/avrxmega2/atxmega32d3
  avr/lib/avrxmega2/atxmega32d4
  avr/lib/avrxmega2/atxmega32e5
  avr/lib/avrxmega3/
  avr/lib/avrxmega3/short-calls/
  avr/lib/avrxmega4/
  avr/lib/avrxmega4/atxmega64a3
  avr/lib/avrxmega4/atxmega64a3u
  avr/lib/avrxmega4/atxmega64a4u
  avr/lib/avrxmega4/atxmega64b1
  avr/lib/avrxmega4/atxmega64b3
  avr/lib/avrxmega4/atxmega64c3
  avr/lib/avrxmega4/atxmega64d3
  avr/lib/avrxmega4/atxmega64d4
  avr/lib/avrxmega5/
  avr/lib/avrxmega5/atxmega64a1
  avr/lib/avrxmega5/atxmega64a1u
  avr/lib/avrxmega6/
  avr/lib/avrxmega6/atxmega128a3
  avr/lib/avrxmega6/atxmega128a3u
  avr/lib/avrxmega6/atxmega128b1
  avr/lib/avrxmega6/atxmega128b3
  avr/lib/avrxmega6/atxmega128c3
  avr/lib/avrxmega6/atxmega128d3
  avr/lib/avrxmega6/atxmega128d4
  avr/lib/avrxmega6/atxmega192a3
  avr/lib/avrxmega6/atxmega192a3u
  avr/lib/avrxmega6/atxmega192c3
  avr/lib/avrxmega6/atxmega192d3
  avr/lib/avrxmega6/atxmega256a3
  avr/lib/avrxmega6/atxmega256a3u
  avr/lib/avrxmega6/atxmega256a3b
  avr/lib/avrxmega6/atxmega256a3bu
  avr/lib/avrxmega6/atxmega256c3
  avr/lib/avrxmega6/atxmega256d3
  avr/lib/avrxmega6/atxmega384c3
  avr/lib/avrxmega6/atxmega384d3
  avr/lib/avrxmega7/
  avr/lib/avrxmega7/atxmega128a1
  avr/lib/avrxmega7/atxmega128a1u
  avr/lib/avrxmega7/atxmega128a4u
  avr/lib/avrtiny/
  avr/lib/avrtiny/attiny4
  avr/lib/avrtiny/attiny5
  avr/lib/avrtiny/attiny9
  avr/lib/avrtiny/attiny10
  avr/lib/avrtiny/attiny20
  avr/lib/avrtiny/attiny40
+ rm -rf autom4te.cache
+ aclocal
+ autoheader
+ autoconf
+ automake --foreign --add-missing --copy
+ cd /home/ubuntixer/toolchain/buildLinux/avr-libc
+ ./config.guess
buildLinux.sh: 1: buildLinux.sh: ./config.guess: not found
+ ../../downloads/avr-libc/configure --prefix=/home/ubuntixer/local/avrLinux64/ --host=avr --build=
checking build system type... x86_64-pc-linux-gnu
checking host system type... avr-unknown-none
checking if configuring for cross compile... yes
checking if target host is avr... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for avr-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for avr-gcc... avr-gcc
checking whether we are cross compiling... yes
checking for suffix of object files... configure: error: in `/home/ubuntixer/toolchain/buildLinux/avr-libc':
configure: error: cannot compute suffix of object files: cannot compile

[Jörg W. (dl8dtl) (Moderator)]

Das hier kennst du aber, oder?

https://nongnu.org/avr-libc/user-manual/install_tools.html

[Veit D. (devil-elec)]

Hallo,

die Seite kenne ich. Die avr Tools soll man unter Linux eigentlich nicht 
installieren, wenn man nur bauen möchte. Um genau den falschen Aufruf zu 
verhindern. Sonst baut der irgendwas und am Ende funktioniert die 
Toolchain nicht. Ich möchte die Toolchain unter Linux nur bauen damit 
ich eine für Windows habe. Ich möchte die Toolchain unter Linux nicht 
installieren.

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:
> Ich möchte die Toolchain unter Linux nur bauen damit ich eine für
> Windows habe.

Öhem, achso. Das war mir entgangen. Also ein Crosscompiler mit einem 
Crosscompiler … Das habe ich allerdings auch noch nicht gemacht. Ich 
benutze MinGW als Crosscompiler bislang nur, um AVRDUDE für Windows 
unter FreeBSD zu bauen.

[Veit D. (devil-elec)]

Hallo,

ja sorry, ich dachte die Info wäre unwichtig, weil es um mein Script 
ging im Eingangsposting. Das ist das erste Script was laufen muss, 
danach würden noch 3 weitere folgen. Ich habe avr c/c++ Toolschain mit 
gcc 7 bis 9 damit gebaut, klappte immer alles.

Ich fasse mal zusammen.
Ich kann bis einschließlich gcc10 mit binutils 2.32 problemlos meine 
C/C++ Toolchain bauen. Ab 2.33.1 gibts Probleme.

Du kannst aber mit binutils 2.34 deine Assembler Toolchain bauen?
Richtig?

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:
> Du kannst aber mit binutils 2.34 deine Assembler Toolchain bauen?

Ja, allerdings native (also build host = execution host), und ich hatte 
dann noch nicht probiert, damit Compiler oder avr-libc zu bauen.

[Veit D. (devil-elec)]

Hallo,

falls du wirklich Langeweile hast, könntest du das einmal bei dir 
testen.  :-)

Ansonsten müßte ich mich an Nick Clifton wenden? Richtig?
Bevor ich jetzt anfange mein Bau-System zu zerfetzen bzw. neu aufsetze, 
würde ich doch gern vorab fragen ob das Problem bekannt ist und ob 
überhaupt so getestet wurde. Nicht das ich mich Tagelang im Kreis drehe.

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:

> falls du wirklich Langeweile hast, könntest du das einmal bei dir
> testen.  :-)

Naja, ich würde dann wohl lieber mal paar Bugs in AVRDUDE schließen, um 
endlich mal ein neues Release rauszubringen. ;-)

> Ansonsten müßte ich mich an Nick Clifton wenden? Richtig?

Bin ich auch gerade nicht im Bilde.

Wenn du einen Buildscript hast, mit dem andere das Problem reproduzieren 
können, und es sich auf genau diese binutils-Version eingrenzen lässt, 
kannst du allemal probieren, dort einen offiziellen Bugreport 
einzutüten.

> Bevor ich jetzt anfange mein Bau-System zu zerfetzen bzw. neu aufsetze,
> würde ich doch gern vorab fragen ob das Problem bekannt ist und ob
> überhaupt so getestet wurde.

Naja, derartige "Canadian Cross" Builds (bei denen build host, execution 
host und target alle verschieden sind) tendieren allgemein dazu, eher 
wenig getestet zu sein.

[Veit D. (devil-elec)]

Hallo,

alles klar, verstehe.   :-)

[Johann L. (gjlayde)]

> configure: error: cannot compute suffix of object files: cannot compile

Schau ins config.log, mit Sicherheit hast du Probleme mit Binutils.

Also sicherstellen, dass Binutils korrekt funktionieren bevor du mit gcc 
oder avr-libc anfängst.

Was sind deine Build-Schritte in Prosa?

[Veit D. (devil-elec)]

Hallo,

das Script hängt am Eingangsthread dran. Ich zerlege das nochmal in alle 
3 Teile ...

Eins kann ich vorab aber schon sagen. Ich kann mir alle Toolchains mit 
binutils 2.32 bauen. Egal ob gcc 8.4, 9.3 oder 10. Nur mit 2.34 gibts 
besagte Probleme.

[Veit D. (devil-elec)]

Hallo,

gestartet mit gcc-10 von 15.03.20 und binutils 2.34

Script und Logfiles hängen dran.

[Johann L. (gjlayde)]

Johann L. schrieb:
> Prosa?

[foobar (Gast)]

> set -x
> ...
> JOBCOUNT=4

Wenn du den Build debuggen willst, wäre ein "set -e" und ein 
"JOBCOUNT=1" sinnvoller.  Das Logfile ist ein heilloses Durcheinander 
mehrerer Prozesse ...

Und check mal den makeinfo-Kram - entweder makeinfo installieren oder 
checken, warum er die neu bauen will (Timestamps überprüfen?).

[Veit D. (devil-elec)]

Hallo,

Prosa:
Was möchtest du hören was nicht besser verständlich im Script steht?

makeinfo installiert, -e und ein Prozessor geändert.
Angehängte Dateien wie gehabt.

[foobar (Gast)]

Na geht doch ;-)

Hatten die älteren Versionen wohl schon fertige texi-Files im Paket.

[Veit D. (devil-elec)]

Hallo,

meine Frage wäre ob nun jemand eine Möglichkeit sieht das Problem mit 
den binutils zu beheben oder nicht?

[foobar (Gast)]

> meine Frage wäre ob nun jemand eine Möglichkeit sieht das Problem mit
> den binutils zu beheben oder nicht?

???  Noch eins?  Der Build ist doch einwandfrei durchgelaufen. * 
verwirrt *

[Veit D. (devil-elec)]

Hallo,

upps, da hats mich selbst verwirrt vor lauter vorheriger 
Fehlermeldungen. Bin gerade am komplett bauen. Das heißt binutils ab 
v2.34 verlangt makeinfo (texinfo) zum bauen?

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:
> Das heißt binutils ab v2.34 verlangt makeinfo (texinfo) zum bauen?

Ist mir zumindest letztens auch aufgefallen. Habe aber nicht analysiert, 
warum sie die Doku neu bauen wollen, hab' einfach texinfo installiert.

[Veit D. (devil-elec)]

Hallo,

Danke, dann wäre das hiermit geklärt.
War eine schwierige Geburt.  :-)
Danke @ all.

[Johann L. (gjlayde)]

foobar schrieb:
> Hatten die älteren Versionen wohl schon fertige texi-Files im Paket.

Es ist ein Unterschied, ob man direkt von den Quellen generiet oder von 
einer releasten Version.  Letzteres brauch weniger Tools und ist i.W. 
das Ergebnis von make dist.

Direkt aus den git Quellen generieren benötigt mehr Tools, dito für GCC.

[Jörg W. (dl8dtl) (Moderator)]

Naja, laut Beschreibung sei texinfo zum Bauen nur nötig, wenn man etwas 
selbst an der Doku ändern würde oder ein kaputtes Buildsystem hätte.

So die Theorie - baue gerade eine Toolchain für ARM, auch dort gingen 
die aktuellen Binutils nicht ohne ein vorhandenes texinfo ab. War mir 
aber zu unwichtig erst zu recherchieren, was da nicht in Ordnung wäre.

[Veit D. (devil-elec)]

Hallo,

avr-libc ist der aktuell runtergeladene trunk. binutils und gcc sind die 
release Pakete. Alles in 3 Ordner entpackt/sortiert und dann gehts los.

[Jedzia D. (Firma: Rast und Ruh) (jedzia)]

Danke für den Krimi:)

Vielleicht ist das für Veit hilfreich:

in meinem Gentoo ebuild lässt sich der makeinfo schritt abschalten. Das 
wird durch

  # Prevent makeinfo from running if doc is unset.
  if ! use doc ; then
    sed -i \
      -e '/^MAKEINFO/s:=.*:= true:' \
      Makefile || die
  fi

gelöst. Siehe 
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/binutils/binutils-2.34.ebuild

Falls Du viel überflüssige Zeit hast (Dein cross-compile Problem hier zu 
lösen hat bestimmt auch Nerven gekostet), kannst du dir ja mal 
https://wiki.gentoo.org/wiki/Crossdev anschauen. Das ermöglicht sowas 
wie

crossdev -s4 -P --verbose -t x86_64-w64-mingw32
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /var/db/repos/cross-avr" x86_64-w64-mingw32-emerge -q -a --autounmask "=sys-devel/gcc-10.0.1_pre9999"

um so eine Toolchain zu bauen. Alles mit den nötigen Abhängigkeiten. 
Oder einfach crossdev -t avr für eine native. Ich verschweige natürlich 
schamlos die Einarbeitungszeit, die zu erstellenden Scripte und die 
Tücken:P

Viel Spass mit den nagelneuen Spielzeugen:)
P.S.: Veit, kann man dein double cross setup irgendwo bewundern? ... die 
Neugier.

[Veit D. (devil-elec)]

Hallo,

die Scripte findest du hier und noch viel Hintergrundinformationen.
Beitrag "cannot read spec file 'device-specs/specs-atmega4808'"
28.07.2019 00:37

[Jedzia D. (Firma: Rast und Ruh) (jedzia)]

Vielen Dank für die Kondensation deiner harten Arbeit in 53 Zeilen, 
Veit:)

[A. B. (Gast)]

Danke an Veit
*************
für die konstante Motivation.

ich habe versucht das oben Beschriebene für mich zu nutzen, um eine 
gcc10_x64 toolchain zu bauen.

es scheitert am fehlenden configure script im Download von
svn co  svn://svn.savannah.nongnu.org/avr-libc/trunk

**********************************************************

[Jörg W. (dl8dtl) (Moderator)]

A. B. schrieb:
> svn co  svn://svn.savannah.nongnu.org/avr-libc/trunk

Wenn du den SVN-Stand der avr-libc nehmen willst, musst du dort den 
bootstrap-Script erstmal laufen lassen. Fertiges configure gibt es nur 
bei den Releases.

[Veit D. (devil-elec)]

Hallo,

startest du die Scripte in der falschen Reihenfolge?

Erst die Linuxbuilds > binutils > gcc > avr-libs
Danach die Windowsbuilds in gleichen Reihenfolge.

[Veit D. (devil-elec)]

Hallo,

weil das Toolchain bauen alleine noch nicht alles ist, habe ich mir .bat 
Dateien gebaut um fehlende Dateien aus dem Devicepack autoelektrisch in 
die Toolchain zu kopieren.

Könnt gern vor der scharfen Anwendung noch die Option /L hinzufügen. 
:-)

Falls sich jemand mit Batch Programmierung und der for Schleife 
auskennt, der könnte bitte zeigen wie man die Controllertypen in eine 
Art Array schreibt die dann abgearbeitet wird. Die langen Listen 
gefallen mir noch nicht wirklich. Deswegen sind die aufgeteilt um den 
Überblick zu behalten.

Die Einzigste Handarbeit die übrig bleibt ist die io.h zubearbeiten.
Für meine Ergänzungen ist die dabei.

[Veit D. (devil-elec)]

Hallo,

habe mir die aktuelle avr Toolchain mit gcc 10.1.0 gebaut.
Jetzt werben die mit folgender Aussage:

Support for the XMEGA-like devices
ATtiny202, ATtiny204, ATtiny402, ATtiny404, ATtiny406, ATtiny804, ATtiny806, ATtiny807, ATtiny1604, ATtiny1606, ATtiny1607, ATmega808, ATmega809, ATmega1608, ATmega1609, ATmega3208, ATmega3209, ATmega4808, ATmega4809

Nur stimmt das doch so gar nicht? Ich komme da nicht mit.
Die Device Spec Files sind vorhanden, aber der notwendige Rest nicht.
Wenn ich in avr\include\avr nachschaue fehlen alle Headerdateien für die 
genannten Controller samt Einträge in die io.h. Warum? Wie muss man die 
Support Aussage verstehen?

"64Bit Double" ist vorhanden. Ist das jetzt so schon für alle AVRs 
nutzbar? Der andere Thread dazu liest sich für mich anders, als wenn 
darauf noch gewartet werden müßte bis es final fertig ist und man es 
dann von Hand einbauen müßte.

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:
> Jetzt werben die

Wer "wirbt"?

avr-libc ist kein Bestandteil des GCC.

[Veit D. (devil-elec)]

Hallo,

im Abschnitt AVR:
https://gcc.gnu.org/gcc-10/changes.html
werden besagte Controller als neu unterstützte Targets hervorgehoben.

Wenn du sagst avr ist kein Bestandteil und die sagen die Controller 
werden unterstützt, dann verstehe ich aktuell gar nichts mehr. 
Betrachten wir den Fall gcc kennt avr gar nicht. Warum schreiben die 
dann etwas von Targetsupport?

[Oliver S. (oliverso)]

Veit D. schrieb:
> Wenn ich in avr\include\avr nachschaue fehlen alle Headerdateien für die
> genannten Controller samt Einträge in die io.h.

Weil

Jörg W. schrieb:
> avr-libc ist kein Bestandteil des GCC.

Der Compiler kann (vermutlich) für die genannten Prozessoren Code 
erzeugen, die avrlibc kennt die aber nicht.

Ist halt so, und überhaupt kein Widerspruch.

Oliver

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:
> Wenn du sagst avr ist kein Bestandteil

Habe ich nicht geschrieben. Ein wenig genauer solltest du schon lesen, 
bevor du auf "die" schimpfst.

Oliver hat die Sache korrekt dargestellt.

[Veit D. (devil-elec)]

Hallo,

wie soll ich denn das gelesene verstehen? Ich verstehe es immer noch 
nicht. Wie will denn der Compiler Code für die genannten Targets 
erzeugen wenn die Headerdateien fehlen? Hier sehe ich einen Widerspruch.

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:
> Wie will denn der Compiler Code für die genannten Targets erzeugen wenn
> die Headerdateien fehlen?

Den Compiler interessieren die Headerdateien schlicht gar nicht. Der 
erzeugt Assemblercode dafür, dafür braucht er keine Bibliothek. 
(Lediglich für weitergehende Schritte wie eine C++-Bibliothek, die beim 
GCC mit dabei ist, würde dann auch eine C-Bibliothek benötigt. Daher 
muss man sowas in zwei Stufen bauen.)

Der Compiler bringt noch ein paar Hilfsfunktionen in einer eigenen 
Bibliothek mit (libgcc.a), aber die haben keinen so direkten 
Hardwarebezug, dass man dafür schon eine C-Bibliothek bräuchte.

Andersrum: die (avr-libc-)Bibliothek braucht, da sie zu einem großen 
Teil selbst in C geschrieben ist, unbedingt zuvor einen funktionierenden 
Compiler für das entsprechende Target. Wenn jetzt auch noch der Compiler 
von der Existenz einer Bibliothek abhängen würde, hätte man ein 
Henne-und-Ei-Problem.

[Veit D. (devil-elec)]

Hallo,

es wird schon heller. Nochmal zum mitmeißeln.  :-)
Der Targetsupport seitens gcc gilt nur für Assembler?
C/C++ Programmierer benötigen die avr-libc?

Noch anders gedacht. Wenn ich das Device-Package von Microchip zur Hand 
nehme bin ich auf den gcc Targetsupport nicht angewiesen, da ich alle 
benötigten Dateien aus dem Device-Package herausnehmen kann.

[Jörg W. (dl8dtl) (Moderator)]

Veit D. schrieb:

> Der Targetsupport seitens gcc gilt nur für Assembler?

Genau genommen gilt er erstmal für den Compiler und die Fähigkeit, C- 
oder C++-Code in Assemblercode zu überführen.

Einen passenden Assembler brauchst du zuvor, in Form der GNU binutils. 
Die sind die ersten, die ein neues Target immer erstmal unterstützen 
müssen.

> C/C++ Programmierer benötigen die avr-libc?

In aller Regel schon, wenngleich es natürlich sehr kleine Projekte geben 
könnte, die keinerlei Support durch die avr-libc benötigen. Dann 
müsstest du aber von A-Z alles selbst machen, was nicht der Compiler 
macht, also insbesondere auch deinen eigenen Startup-Code liefern.

> Noch anders gedacht. Wenn ich das Device-Package von Microchip zur Hand
> nehme bin ich auf den gcc Targetsupport nicht angewiesen, da ich alle
> benötigten Dateien aus dem Device-Package herausnehmen kann.

Die haben ihre device packages halt so aufgebaut, dass sie da alles drin 
haben.

[Veit D. (devil-elec)]

Hallo,

ich denke ich habs verstanden. Vielen Dank.

[Johann L. (gjlayde)]

Veit D. schrieb:
> habe mir die aktuelle avr Toolchain mit gcc 10.1.0 gebaut.
> Jetzt werben die mit folgender Aussage:
>
> Support for the XMEGA-like devices [...]

Das ist keine Webung sondern schlicht eine Beschreibung dessen, was sich 
von einer Compilerversion zur nächsten (ge)ändert (hat).  Wie man es für 
jede enstzunehmende Software erwartet.

Es bedeutet: Der Compiler unterstützt den jeweiligen Core (in allen 
Fällen "avrxmega3", was schon seit v8 der Fall ist) und der erzeugt 
specs-Files für die genannten Devices.  That's it.

Ohne Release Notes wäre der Compiler ein riesiges Nest voller 
Easter-Eggs; die per Zufall zu entdecken, oder die Quelle lesen zu 
müssen um zu erfahren was sich ändert, wär dir vermutlich auch nicht 
recht.  Wie man's macht ist's falsch...

Ob die avr-libc die Devices unterstützt musst du avr-libc gucken.  Es 
gibt unterschiedliche Versionen von Patches für die Devices, die m.W. 
(noch) nicht eingebaut sind.

http://savannah.nongnu.org/patch/?9543

Die avr-libc unterstützt ein bestimmtes Device wenn

1) Die abvr-libc das Device unterstützt

2) UND der Compiler das Device unterstützt, d.h. die entsprechende -mmcu 
Option akzeptiert.  Falls nicht, lässt avr-libc configure das Device 
links liegen.

> Wenn ich in avr\include\avr nachschaue fehlen alle Headerdateien für die
> genannten Controller samt Einträge in die io.h. Warum? Wie muss man die
> Support Aussage verstehen?

Für Features von GCC liest du die GCC Release Notes, speziell für 
avr-gcc den Abschnitt "AVR" — sofern vorhanden:

http://gcc.gnu.org/gcc-10/changes.html#avr

Für Features der avr-libc liest du die avr-libc Release Notes.  Falls du 
eine noch nicht releaste Revision verwendest wie SVN trunk, dann 
möchtest du auch ChangeLog(s) oder NEWS Datei lesen:

http://svn.savannah.nongnu.org/viewvc/avr-libc/trunk/avr-libc/

> "64Bit Double" ist vorhanden. Ist das jetzt so schon für alle AVRs
> nutzbar?

avr-gcc: Ja. Wobei die avr-libc für Devices ohne MUL keine Funktionen 
implementiert, für welche Devices mit MUL diese Instruktion nutzen. Du 
bekommst dann eine "undefined reference" vom Linker und dein Projekt 
kann sie beisteuern.  Für reduced Tiny fehlen alle Funktionen, mit 
entsprechenden Optionen erzeugt der Compiler allerding korrekten Code 
für 64-Bit (long) double so wie für andere Cores auch.  Auch hier bist 
du darauf angewiesen, 64-Bit double Funktionen selber zu schreiben.  Wie 
sinnvoll das für einen reduced Tiny ist sei dahingestellt.

avr-libc:

http://savannah.nongnu.org/bugs/?49567
http://savannah.nongnu.org/bugs/?57071

Ohne die Patches bekommst du falschen Code weil avr-libc die 
entsprechenden Multilib-Varianten nicht erzeugt, und weil die Funktionen 
falsch benannt sind, z.B. heißt sinf nicht "sinf" sondern "sin"; dito 
für alle anderen float-Funktionen.  Bedeutet konkret, dass sin nur 
32-Bit float liefert egal was du in die avr-libc reinfütterst (abgesehen 
von den obigen Patches natürlich :o)

Du hast also 3 großflächige Patches anzuwenden.

Spoiler: Weil einige Patches nicht mehr ganz taufrisch sind, gibt es 
(nicht-triviale) Konflikte.

[Veit D. (devil-elec)]

Hallo,

Danke, dass muss ich mir nochmal in Ruhe zu Gemüte führen.

[Veit D. (devil-elec)]

Hallo,

habe meine Batchdateien nochmals überarbeitet, jetzt mit relativen 
Pfaden und nochmal leicht umgebaut. Für Atmegas und ATtinys getrennt. 
Header und Lib .bat müssen "zusammen" gestartet werden.

Also wie folgt. Irgendwo einen Ordner erstellen zum Toolchain ergänzen.
Da rein die .bat Dateien ohne weiteren Unterordner.
Da rein die entpackten DevicePacks mit einem Unterordner. (in .zip 
umbennen, http://packs.download.atmel.com/)
Da rein deine Toolchain mit einem Unterordner.
Den Ordnernamen vom Devicepack und Toolchain ändert ihr in den .bat 
Dateien ab und könnt einen Testlauf starten. Ich nutze dafür robocopy, 
die Option /L ist aktiv. Wenn alles gut aussieht nehmt ihr die Optionen 
/L raus, dann ist das alles scharf geschalten. Ihr müsst immer nur die 
ersten 3 Zeilen je .bat anpassen.

Am Ende müßt ihr aber noch die io.h anpassen und die Einträge machen. 
Dafür habe ich keine .bat Datei.

/* ATmega328PB */
#elif defined (__AVR_ATmega328PB__)
#  include <avr/iom328pb.h>
/* begin new ATmegas */
#elif defined (__AVR_ATmega808__)
#  include <avr/iom808.h>
#elif defined (__AVR_ATmega809__)
#  include <avr/iom809.h>
#elif defined (__AVR_ATmega1608__)
#  include <avr/iom1608.h>
#elif defined (__AVR_ATmega1609__)
#  include <avr/iom1609.h>
#elif defined (__AVR_ATmega3208__)
#  include <avr/iom3208.h>
#elif defined (__AVR_ATmega3209__)
#  include <avr/iom3209.h>
#elif defined (__AVR_ATmega4808__)
#  include <avr/iom4808.h>
#elif defined (__AVR_ATmega4809__)
#  include <avr/iom4809.h>
/* end new ATmegas */
/* begin new ATtinys */
#elif defined (__AVR_ATtiny202__)
#  include <avr/iotn202.h>
#elif defined (__AVR_ATtiny204__)
#  include <avr/iotn204.h>
#elif defined (__AVR_ATtiny212__)
#  include <avr/iotn212.h>
#elif defined (__AVR_ATtiny214__)
#  include <avr/iotn214.h>
#elif defined (__AVR_ATtiny402__)
#  include <avr/iotn402.h>
#elif defined (__AVR_ATtiny404__)
#  include <avr/iotn404.h>
#elif defined (__AVR_ATtiny406__)
#  include <avr/iotn406.h>
#elif defined (__AVR_ATtiny412__)
#  include <avr/iotn412.h>
#elif defined (__AVR_ATtiny414__)
#  include <avr/iotn414.h>
#elif defined (__AVR_ATtiny416__)
#  include <avr/iotn416.h>
#elif defined (__AVR_ATtiny417__)
#  include <avr/iotn417.h>
#elif defined (__AVR_ATtiny804__)
#  include <avr/iotn804.h>
#elif defined (__AVR_ATtiny806__)
#  include <avr/iotn806.h>
#elif defined (__AVR_ATtiny807__)
#  include <avr/iotn807.h>
#elif defined (__AVR_ATtiny814__)
#  include <avr/iotn814.h>
#elif defined (__AVR_ATtiny816__)
#  include <avr/iotn816.h>
#elif defined (__AVR_ATtiny817__)
#  include <avr/iotn817.h>
#elif defined (__AVR_ATtiny1604__)
#  include <avr/iotn1604.h>
#elif defined (__AVR_ATtiny1606__)
#  include <avr/iotn1606.h>
#elif defined (__AVR_ATtiny1607__)
#  include <avr/iotn1607.h>
#elif defined (__AVR_ATtiny1614__)
#  include <avr/iotn1614.h>
#elif defined (__AVR_ATtiny1616__)
#  include <avr/iotn1616.h>
#elif defined (__AVR_ATtiny1617__)
#  include <avr/iotn1617.h>
#elif defined (__AVR_ATtiny3214__)
#  include <avr/iotn3214.h>
#elif defined (__AVR_ATtiny3216__)
#  include <avr/iotn3216.h>
#elif defined (__AVR_ATtiny3217__)
#  include <avr/iotn3217.h>
/* end new ATtinys*/

Das wars. Ich hoffe das erleichtert dem Einen oder Andere die Arbeit. 
:-)