Forum: Mikrocontroller und Digitale Elektronik cannot read spec file 'device-specs/specs-atmega4808'


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich stehe nach einer frischen Win10 Installation erneut vor dem Problem 
das ich keine leeren Projekte mit dem ATmega4808 kompilieren kann.


Projekt in AS7 erstellt:
"cannot read spec file 'device-specs/specs-atmega4808': No such file or 
directory"

Projekt mit Atmel Start erstellt:
skipping incompatible c:/users/devil/documents/atmel 
studio/7.0/toolchain/avr-gcc-9.1.0_mingw32/bin/../lib/gcc/avr/9.1.0/../. 
./../../avr/lib\libm.a  when searching for -lm

Öffne ich dagegen ein altes damals erstelltes Projekt kompiliert es.
Im AS Paketmanager ist ATmega_DFP 1.2.209, 1.2.272 und 1.3.300 
installiert.
Ich weiß nicht was schief läuft.
Ältere ATmegas und ATtinys machen keine Probleme.
Aktuell verwendeter Compiler ist avr-gcc-9.1
Wechsel auf "Nativen" macht keinen Unterschied.

Ideen?
Was fehlt?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Du brauchst die Files für den Device-Support an den richtigen Stellen: 
specs-atmega4808, libatmega4808.a, iox4808.h.

Übersetzt das alte Projekt mit -v und schau in der Ausgabe, von wo diese 
Dateien bezogen werden.

Komisch ist außerdem das "\libm.a", sollte eher heißen 
"/avrxmega3/libm.a".

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

ganz ehrlich, ich werde nicht schlau daraus. Suche ich in den Ausgaben 
nach "4809" steht alles in einem ATmega_DFP Pfad. Laut meiner Meinung 
alles Standard. Ausgabe mit -v vom altes Projekt was kompiliert im 
Anhang.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Ändere ich auf avr-gcc 9.1.0 und mache Build kompiliert es noch. Mache 
ich Rebuild Solution erhalte ich das hier mit Fehler.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Ich sehe das es kein cpp sondern ein c Projekt ist.
Jetzt könnte man denken das alles mit der nativen Toolchain und C (kein 
C++) kompiliert.
Neues C Projekt erstellt mit nativer Toolchain ... kompiliert wieder 
nicht.
"device-specs/specs-atmega4808: No such file or directory  C_Test 
avr-gcc.exe  0"

Nochmal altes C Projekt geöffnet was mit Atmel Start erstellt wurde.
Mit nativer Toolchain klappt alles.
Wechsel ich auf den aktuellen avr-gcc-9.1.0 klappt es noch mit Build.
Mit Rebuild wieder nicht mehr. "pseudo instruction `__gcc_isr' not 
supported"

Suche ich in den obigen Ausgaben nach "4809" steht alles in einem 
ATmega_DFP Pfad. Laut meiner Meinung alles Standard.

Jetzt habe ich einmal von dem kompilierenden Projekt alle Einstellungen 
sichtbar gemacht.
Kann es was mit dem fehlenden GDB Pfad zu tun haben?

Mein Ziel/Wunsch ist es die neuen µC auch in C++ mit aktuellen avr-gcc 
programmieren zu können. Klappte bisher auch. Verstehe noch nicht warum 
die neuen sich nicht einfach einfügen.

Ideen was hier schief läuft?

von Veit D. (devil-elec)


Lesenswert?

Schaue ich im Pfad vom avr-gcc-9.1.0 nach finde ich den Header zum 4809 
und andere.

C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\include\avr\iom4809.h
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\libatmega4809.a
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\crtatmega4809.o
C:\avrToolchain\avr-gcc-9.1.0_mingw32\lib\gcc\avr\9.1.0\device-specs\spe 
cs-atmega4809

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Das alte Projekt compiliert mit
1
-I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\include"

und compilert und linkt mit
1
-B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\gcc\dev\atmega4809"

das muss beim neuen Projekt auch zu den entsprechenden Optionen (oder 
die DFPs zum Projekt hinzufügen falls so'n Feature gibt, das das 
automatisch handelt).  Neuere Compiler linken gegen die Device-Lib 
(libatmega4809.a), es muss also mit entsprechendem -L 
Pfad-zur-Device-Lib gelinkt werden, oder mit -nodevicelib falls keine 
Funktionen daraus (eeprom etc.) verwendet werden.

Außerdem schreibst du von atmega4808, im Projekt wird aber atmega4809 
verwendet.
1
-Wl,--start-group -Wl,-lm  -Wl,--end-group

ist überflüssig, auch wenn's nix mit deinem Problem zu tun hat.  Wenn 
Linken ohne diese Option nicht funktioniert, dann gibt es ein Problem 
mit der Installation selbst.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Schaue ich im Pfad vom avr-gcc-9.1.0 nach finde ich den Header zum 4809
> und andere.
>
> C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\include\avr\iom4809.h
> C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\libatmega4809.a
> C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\crtatmega4809.o
> C:\avrToolchain\avr-gcc-9.1.0_mingw32\lib\gcc\avr\9.1.0\device-specs\spe 
cs-atmega4809

Dann sollte -mmcu=atmega4809 beim Compilieren und Linken genügen, es 
braucht dann kein extra -I, -B, -L zu den Packs die v5.4 verwendet.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Wo muss ich das eintragen?

In den Toolchain Settings > AVR/GNU Common > General
steht in Zeile "Target Device Name:"
genau das -mmcu=atmega4809 grau hinterlegt drin.

Auch die Pfade bei C++ Compiler > Directories > einfügen hilft nicht.
cannot read spec file 'device-specs/specs-atmega4809': No such file or 
directory  test  avr-g++.exe  0

Warum ist das so kompliziert?

Wegen 4808 / 4809, beim neuen Projekt erstellen verklickt man sich in 
der Aufregung. Für einen Kompiliertest sicherlich egal. Ansonsten achte 
ich schon darauf.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Wo muss ich das eintragen?

Kann ich dir nicht sagen, ich verwende kein Atmel Studio.

Es gibt auch den Fehler "error: pseudo instruction `__gcc_isr' not 
supported" der auftritt, denn man ein (altes) specs-File verwendet, dass 
nicht zur Compilerversion v8+ passt.  Müsste sich mit Entfernen der -B 
Option beheben lassen.

Falls nicht, wurden alte specs in neue Tools kopiert ohne sie 
anzupassen.  In diesem Fall muss folgende spec hinzugefügt werden (3 
Zeilen):
1
*asm_gccisr:
2
  %{!mno-gas-isr-prologues: -mgcc-isr}

von Veit D. (devil-elec)


Lesenswert?

Schade das du kein AS hast. Das hilft mir so leider nicht weiter. Ich 
weiß nicht wo ich was einfügen muss. Wie/Womit programmierst und 
kompilierst du? So nebenbei gefragt.

Ich habe jetzt für C und C++ wieder die native Toolchain auf Default 
gesetzt.
Jetzt kompilieren auch neu angelegte Projekte mit den neuen µC.
Davon habe ich aktuelle Einstellungen notiert.
1
AVR/GNU Common > General > Target Device Name:
2
    -mmcu=atmega4808 -B "$(PackRepoDir)\atmel\ATmega_DFP\1.3.300\gcc\dev\atmega4808"
3
    
4
AVR/GNU Common > General > Default Include Paths:
5
    C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include
6
    C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\lib\gcc\avr\5.4.0\include
7
    C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\lib\gcc\avr\5.4.0\include-fixed
8
    
9
AVR/GNU C++ Compiler > Command:
10
    avr-g++
11
12
AVR/GNU C++ Compiler > All Options: (alles in einer Zeile)
13
  -funsigned-char -funsigned-bitfields -DNDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\include"
14
  -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -mmcu=atmega4808 -B 
15
  "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\gcc\dev\atmega4808" -c -MD -MP -MF "$(@:%.o=%.d)"
16
  -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" 
17
  
18
AVR/GNU Linker > Command:  
19
  avr-g++
20
  
21
AVR/GNU Linker > All Options: (alles in einer Zeile)
22
  -Wl,-Map="$(OutputFileName).map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=atmega4808
23
  -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\gcc\dev\atmega4808"

Wenn du mir sagen könntest was ich davon für den gcc9.1. übernehmen und 
nicht übernehmen darf wäre mir schon geholfen für das weitere im trüben 
fischen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Davon habe ich aktuelle Einstellungen notiert.

Wenn die v9 Support für ATmega4808/9 mitbringt, dann einfach alle 
Optionen rauskicken, in denen "Atmel" vorkommt.  Der Compiler findet 
dann Libs, Specs, Crt, Header von selbst.  Und das 
-Wl,--start-group,-lm,--end-group kann bei beiden raus.

Die neuen Versionen (ab v8) bringen einige Optimierungen wie die des 
ISR-Prologs, es ist also wünschenswert, neue Tools zu verwenden.  Das 
Feature wird im GAS aber nur aktiv, wenn die entsprechende Option 
gesetzt ist.  Dies führt dann zu Problemen, wenn man alte Specs (die die 
Option nicht beinhalten) mit neuen Tools verwendet.  Daher die Probleme 
mit -B etc.

Und für Devices in avrxmega3 wie z.B. ATmega4808/9 brauchts auch kein 
__flash oder PROGMEM mehr, weil .rodata ins Flash lokatiert werden kann 
denn diese Devices haben einen lineare Adressraum, d.h. es kann mit LDS 
/ LDD aus dem Flash gelesen werden.

Welcher Fehler kommt denn bei v9 wenn alle "Atmel"-Optionen rausgeworfen 
sind?  Evtl. das verwendete specs-atmega4809 anhängen, ist nur Text.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe alles rausgenommen was möglich ist, vieles ist grau hinterlegt und 
nicht änderbar. Kompiliert leider nicht. Wenn ich ihm Pfade mit auf dem 
Weg gebe scheint er sie nicht zu übernehmen bzw. zu durchsuchen - so 
mein Gefühl.

Ich drehe mich zur Zeit im Kreis. Für heute machen wir erstmal Schluss, 
sonst drehe ich noch am Zeiger.

Danke erstmal für deine Zeit und Unterstützung. Ab morgen wieder ... 
:-)


Ich fasse nochmal zusammen. AS7 macht mit der nativen Toolchain keine 
Probleme. Weder mit C noch C++ noch alten und neuen µC. Erst wenn man 
versucht eine aktuelle Toolchain wie avr-gcc-9.1 zuverwenden gehts los. 
Dann funktioniert alles noch mit den alten µC aber mit den neuen 
ATmegas/ATtinys nicht mehr. Auch egal ob avr-gcc 7.3 oder 8.2. AS findet 
die benötigten Dateien nicht mehr.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe mir heute den Pfad von der nativen Toolchain und den vom gcc 9.1 
vorgenommen und alles von 9.1 in die passenden Ordner der nativen 
kopiert und vorher alles gelöscht. Ich habe ihm damit die 9.1er als 
seine Native direkt unter die Nase schieben wollen. Zum eigenen 
Erstaunen lassen sich Projekte mit alten µC kompilieren. Aber mit den 
neuen immer noch nicht.
Immer wieder "cannot read spec file 'device-specs/specs-atmega4808': No 
such file or directory".
Ich weiß nicht wie ich AS sagen soll wo es hingucken muss. Liegt doch 
alles vor der Nase. Hat irgendwer Ideen?

: Bearbeitet durch User
von Veit D. (devil-elec)



Lesenswert?

Hallo,

es gibt Neuigkeiten. Gestern hatte ich auf der Platte nach den Dateien 
für den ATmega4809 gesucht, die soweit vorhanden sind. Jedoch zum testen 
immer Projekte mit dem ATmega4808 erstellt. Dachte sind eh fast die 
gleichen µC, wenn das eine geht muss auch das andere gehen. Was für ein 
Fehler.

Das gibts wie gesagt alles.
1
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\include\avr\iom4809.h
2
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\libatmega4809.a
3
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\crtatmega4809.o
4
C:\avrToolchain\avr-gcc-9.1.0_mingw32\lib\gcc\avr\9.1.0\device-specs\specs-atmega4809

Aber für den 4808 gibts nichts in \lib\avrxmega3\ und auch keine 
device-specs
Es gibt nur ein Headerfile in avr\include\avr\iom4808.h

Kein Wunder das AS kein device-spec finden kann.

Daraufhin habe ich die 9.1 Toolchain von 
http://blog.zakkemble.net/avr-gcc-builds/ nochmal geladen und muss 
feststellen das es jetzt auch nichts mehr für den 4809 gibt. Einfach 
weg. Verrückt. Nur von wo soll die 4809.h sonst sein. Habe ja nichts 
anderes.

Erstelle ich jetzt ein C++ Projekt mit dem ATmega4809 erhalte ich 
folgende Fehler.
1
skipping incompatible c:/avrtoolchain/avr-gcc-9.1.0_mingw32/bin/../lib/gcc/avr/9.1.0/../../../../avr/lib\libm.a when searching for -lm
2
3
cannot find -lm
4
5
recipe for target 'GccApplication1.elf' failed  GccApplication1  C:\Users\devil\Documents\Atmel Studio\7.0\Workspace_ATmega4809\GccApplication1\GccApplication1\Debug\Makefile  106

Kann man das korrigieren?

Hat irgendwer die fehlenden Dateien zur megaavr0 Serie?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

die fehlenden Dateien habe ich jetzt vom Atmel.ATmega_DFP.1.3.300.atpack 
einsortiert.

Bleibt aktuell die Frage übrig wie man das korrigieren kann.
1
skipping incompatible c:/avrtoolchain/avr-gcc-9.1.0_mingw32/bin/../lib/gcc/avr/9.1.0/../../../../avr/lib\libm.a when searching for -lm
2
3
cannot find -lm
4
5
recipe for target 'GccApplication1.elf' failed  GccApplication1  C:\Users\devil\Documents\Atmel Studio\7.0\Workspace_ATmega4809\GccApplication1\GccApplication1\Debug\Makefile  106

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Schau mal ob du die neuesten Device-Packs von Microchip findest.

Von Zak gibt's vermutlich nur 'nen vanilla-Build, d.h. ohne eigene 
Patches oder Erweiterungen.  Der Compiler kann die Specs für ATmega4808 
(noch) nicht generieren, die Dateien sind also Handarbeit.

Evtl. kannst du auch die Dateien von v5.4 kopieren, wichtig ist dass 
diese für avrxmega3 sind und nicht für avrxmega2.  Und dass die o.g. 
asm_gccisr Spec vorhanden ist, deren Fehlen ja den Error bei der v9 
verursachte.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Erstelle ich jetzt ein C++ Projekt mit dem ATmega4809 erhalte ich
> folgende Fehler.
> [code]
> skipping incompatible
> c:/avrtoolchain/avr-gcc-9.1.0_mingw32/bin/../lib/gcc/avr/9.1.0/../../../ 
../avr/lib\libm.a
> when searching for -lm
>
> cannot find -lm

Da stimmt irgendwas nicht mit den Multilib-Pfaden.  Sind noch irgendwo 
-L Lib-Pfade fürs Linken eingetragen?

Könnte auch sein dass ohne -mmcu=atmega4809 gelinkt wird, dann wird die 
Default-Multilib (avr2) genommen anstatt die avrxmega3.

Hat das Entfernen von -lm samt start-end-Group bei den Linkeroptionen 
einen Effekt?

Wie sieht denn das space-atmega4809 aus?

von Veit D. (devil-elec)


Lesenswert?

Hallo Johann,

scheinbar habe ich die Lösung gefunden. Du auch.  :-)  Deckt sich mit 
deiner vorletzten Antwort. Nachdem ich das gelesen hatte 
https://www.avrfreaks.net/forum/atmega4809-and-avr-libc, Beitrag #4.
Ich habe die beiden Dateien libc.a und libm.a von der nativen Toolchain
1
C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\lib\avrxmega3
in der 9.1er Toolchain ersetzt
1
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib

Die anderen Dateien hatte ich vorhin schon aus dem DFP Pack kopiert.
Ein leeres Projekt kompiliert erstmal.  :-)
Ein erster Registerzugriff kompiliert auch.
PORTA.DIR = 1;
Scheint erstmal zu funktionieren.
Mal wie sich das weiter entwickelt.

Ich danke für die Unterstützung und mitdenken.  :-)

Kann man hoffen das der Fehler in der nächsten Toolchainversion behoben 
ist? Oder kann man jemanden irgendwo anschreiben? Scheinbar hats noch 
niemand gemacht? Der Dateiaustausch kann ja kein Dauerzustand bleiben.

Übrigens. Wenn du kein AS hast, wie programmierst und kompilierst du?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Nachdem ich das gelesen hatte
> https://www.avrfreaks.net/forum/atmega4809-and-avr-libc, Beitrag #4.
> Ich habe die beiden Dateien libc.a und libm.a von der nativen Toolchain
>
1
> C:\Program Files 
2
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\lib\avrxmega3
3
>
> in der 9.1er Toolchain ersetzt
>
1
> C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib
2
>

Das ist definitiv falsch.  Wenn die Libs in avr/lib/avrxmega3 nicht 
gefunden werden, dann liegt das Problem woanders.  Die Libs für avr2 zu 
ersetzen kann nicht der Weg sein!

Gibt es denn in der v9 ein avr/lib/avrxmega3, und sind da libm.a und 
libc.a mit der richtigen Architektur ? Also avr:103 in
1
$ avr-objdump -x  ...\avr\lib\avrxmega3\libm.a | grep arch
2
architecture: avr:103, flags ...

Und ist avrxmega3 die Architektur in den Specs?

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Kann man hoffen das der Fehler in der nächsten Toolchainversion behoben
> ist?

Ich wüsste nicht dass die Tools da nen Fehler haben.  Scheint eher ein 
Problem mit der Installation / Distribution zu sein oder mit den 
Optionen / Pfaden im AS.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

v8 gibt mit
1
avr-gcc main.c -v -mmcu=attiny3214

u.a. folgende Ausgabe:
1
COMPILER_PATH=$INSTALL/bin/../libexec/gcc/avr/8.0.1/;$INSTALL/bin/../libexec/gcc/;$INSTALL/bin/../lib/gcc/avr/8.0.1/../../../../avr/bin/
2
LIBRARY_PATH=$INSTALL/bin/../lib/gcc/avr/8.0.1/avrxmega3/;$INSTALL/bin/../lib/gcc/avr/8.0.1/../../../../avr/lib/avrxmega3/;$INSTALL/bin/../lib/gcc/avr/8.0.1/;$INSTALL/bin/../lib/gcc/;$INSTALL/bin/../lib/gcc/avr/8.0.1/../../../../avr/lib/
3
COLLECT_GCC_OPTIONS='-v'  '-specs=device-specs/specs-attiny3214' '-mmcu=avrxmega3'
4
 $INSTALL/bin/../libexec/gcc/avr/8.0.1/collect2.exe -plugin $INSTALL/bin/../libexec/gcc/avr/8.0.1/liblto_plugin-0.dll -plugin-opt=$INSTALL/bin/../libexec/gcc/avr/8.0.1/lto-wrapper.exe -plugin-opt=-fresolution=c:\Temp\ccjDbVF7.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lattiny3214 -mavrxmega3 -Tdata 0x803800 $INSTALL/bin/../lib/gcc/avr/8.0.1/../../../../avr/lib/avrxmega3/crtattiny3214.o -L$INSTALL/bin/../lib/gcc/avr/8.0.1/avrxmega3 -L$INSTALL/bin/../lib/gcc/avr/8.0.1/../../../../avr/lib/avrxmega3 -L$INSTALL/bin/../lib/gcc/avr/8.0.1 -L$INSTALL/bin/../lib/gcc -L$INSTALL/bin/../lib/gcc/avr/8.0.1/../../../../avr/lib c:\Temp\ccjZX5nC.o --start-group -lgcc -lm -lc -lattiny3214 --end-group
5
COLLECT_GCC_OPTIONS='-v'  '-specs=device-specs/specs-attiny3214' '-mmcu=avrxmega3'

Für v9 und -mmcu=atmega4809 muss das bei deiner Installation analog 
sein! Beachte insbesondere das 
LIBRARY_PATH=LIBRARY_PATH=$INSTALL/bin/../lib/gcc/avr/8.0.1/avrxmega3/;$ 
INSTALL/bin/../lib/gcc/avr/8.0.1/../../../../avr/lib/avrxmega3/;...

Der Compiler(treiber) versorgt den Linker also mit den korrekten 
Multilib-Pfaden für avrxmega3.

Irgendwo spuckt dir da AS in die Suppe. Oder Zak hat die Tools komisch 
configured?

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

okay, habe den Speicherort der libc.a und libm.a korrigiert. Die 
orignalen wiederhergestellt und diese der Nativen in den 
\avr\lib\avrxmega3 Ordner geschoben. Soweit alles gut.

Wenn ich mit Option -v kompiliere erhalte ich folgende Ausgabe, siehe 
Anhang

Das "ignoring nonexistent directory" macht mich noch unruhig. ?
Obwohl es fehlerfrei kompiliert. ?

Auszug:
1
GNU C++14 (GCC) version 9.1.0 (avr)
2
      compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
3
    GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
4
    ignoring nonexistent directory "c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/../../../../avr/include/c++/9.1.0"
5
    ignoring nonexistent directory "c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/../../../../avr/include/c++/9.1.0/avr/avrxmega3"
6
    ignoring nonexistent directory "c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/../../../../avr/include/c++/9.1.0/backward"
7
    ignoring nonexistent directory "c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/../../../../avr/sys-include"
8
    ignoring nonexistent directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/../../../../avr/include/c++/9.1.0"
9
    ignoring nonexistent directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/../../../../avr/include/c++/9.1.0/avr/avrxmega3"
10
    ignoring nonexistent directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/../../../../avr/include/c++/9.1.0/backward"
11
    ignoring duplicate directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/include"
12
    ignoring duplicate directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/include-fixed"
13
    ignoring nonexistent directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/../../../../avr/sys-include"
14
    ignoring duplicate directory "c:/avrtoolchain/avr-gcc-9.1.0_mingw32/lib/gcc/../../lib/gcc/avr/9.1.0/../../../../avr/include"
15
    #include "..." search starts here:
16
    #include <...> search starts here:
17
     C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\ATmega_DFP\1.3.300\include
18
     c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/include
19
     c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/include-fixed
20
     c:\avrtoolchain\avr-gcc-9.1.0_mingw32\bin\../lib/gcc/avr/9.1.0/../../../../avr/include
21
    End of search list.


Ansonsten scheint ddas mit dem Compiler Path und Library Path zu passen 
wie ich das überblicke.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Das "ignoring nonexistent directory" macht mich noch unruhig. ?

Die Meldungen sind üblich.

> Obwohl es fehlerfrei kompiliert. ?

Ich dachte es gibt einen Fehler beim Compilieren?

Seltsam ist
1
    rename spec link to old_link
Was bedeutet das?  Vom Compiler kommt das nicht. Patcht AS die link Spec 
im specs-File?

Und AS unterschlägt einen Teil der Ausgabe, ich sehe z.B. nicht den 
Aufruf von collect2.exe.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

Johann L. schrieb:
> Veit D. schrieb:
>> Das "ignoring nonexistent directory" macht mich noch unruhig. ?
>
> Die Meldungen sind üblich.

dann bin ich beruhigt.  :-)

>> Obwohl es fehlerfrei kompiliert. ?
>
> Ich dachte es gibt einen Fehler beim Compilieren?

Seit dem kopieren von libm.a und libc.a kompiliert es fehlerfrei.

> Seltsam ist
>
1
> rename spec link to old_link
2
>
> Was bedeutet das?  Vom Compiler kommt das nicht. Patcht AS die link Spec
> im specs-File?

Was es mit dem Rename auf sich hat kann ich nicht sagen. Bin froh das es 
überhaupt kompiliert.
Kann und sollte ich dem nachgehen? Was müßte ich dafür machen?

> Und AS unterschlägt einen Teil der Ausgabe, ich sehe z.B. nicht den
> Aufruf von collect2.exe.

collect2 habe ich noch nicht gesehen. Auch mit der nativen Toolchain 
erscheint kein collect2. Habe die Ausgaben danach zusätzlich durchsuchen 
lassen. Wofür wäre das gut?

Edit:
Ich glaube mich zu erinnern das ich collect2 Ausgaben nur sehe wenn es 
bestimmte Compilerfehler gibt.

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

Danke nochmal Johann für deine Hilfe.

Ich fasse die Ereignisse zusammen.

Wenn man für C++ eine neue Toolchain 
(http://blog.zakkemble.net/avr-gcc-builds/) mit µC der neuen megaAVR 
0-series verwenden möchte,
dann muss man folgende Änderungen für Atmel Studio 7 vornehmen. Stand 
heute.  :-)

Meine Zakkemble Toolchain liegt im Verzeichnis 
C:\avrToolchain\avr-gcc-9.1.0_mingw32\

allgemeiner Teil 1, wobei das letzte Verzeichnis auch µC abhängig ist:

Die beiden Dateien libc.a und libm.a von der nativen AS7 Toolchain
1
C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\lib\avrxmega3\
in die 9.1er Toolchain einfügen (fehlendes Verzeichnis "avrxmega3" 
anlegen)
1
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\


µC spezifischer Teil 2:

Wenn Atmel Studio 7 auf dem aktuellen Stand ist liegt das aktuelle DFP 
Pack schon auf der Platte.
Ansonsten > AS7 starten > Tools > Device Pack Manager, liegt im Pfad
1
C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.3.300\gcc\dev\

Oder man holt sich das Microchip Packs Repository (...DFP...) von hier 
http://packs.download.atmel.com/
In .zip oder .rar umbenennen und entpacken. Ich empfehle aktuell alles 
auf dem gleichen Stand zu halten.


Bsp. für ATmega4808:

folgende specs Datei aus dem ATmega_DFP Pack kopieren
von
C:\Users\devil\Downloads\Atmel.ATmega_DFP.1.3.300.atpack\gcc\dev\atmega4 
808\device-specs\specs-atmega4808
nach
C:\avrToolchain\avr-gcc-9.1.0_mingw32\lib\gcc\avr\9.1.0\device-specs\
kopieren

und die Dateien crtatmega4808.o und libatmega4808.a
von
C:\Users\devil\Downloads\Atmel.ATmega_DFP.1.3.300.atpack\gcc\dev\atmega4 
808\avrxmega3
nach
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\
kopieren

//---------------------------------------------------------------------

weiteres Bsp. für ATmega4809:

die beiden Dateien von
C:\Users\devil\Downloads\Atmel.ATmega_DFP.1.3.300.atpack\gcc\dev\atmega4 
809\device-specs\specs-atmega4809
kopiert man dann wiederum nach
C:\avrToolchain\avr-gcc-9.1.0_mingw32\lib\gcc\avr\9.1.0\device-specs\

und die Dateien crtatmega4809.o und libatmega4809.a
von
C:\Users\devil\Downloads\Atmel.ATmega_DFP.1.3.300.atpack\gcc\dev\atmega4 
809\avrxmega3\
ebenfalls nach
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Wenn man für C++ eine neue Toolchain
> (http://blog.zakkemble.net/avr-gcc-builds/) mit µC der neuen megaAVR
> 0-series verwenden möchte, dann muss man folgende Änderungen
> für Atmel Studio 7 vornehmen. Stand heute.  :-)
>
> Die beiden Dateien libc.a und libm.a von der nativen AS7 Toolchain
>
1
$INSTALL\avr\lib\avrxmega3\

D.h. in der Installation von Zak gibt es keine libc Multilibs für 
avrxmega3 und avrxmega3/short-calls ? (Die libgcc.a liegt in anderen 
Pfaden und kommt von GCC, die müssten also auf jeden Fall anbei sein.)

Das kann eigentlich nur bedeuten, dass Zak die avr-libc aus einer 
Release generiert hat anstatt aus SVN trunk.  IIRC enthält nur letztere 
die Erweiterung für avrxmega3.

Und wenn GCC irgendeine Multilib nicht findet (hier: 
avrxmega3[/short-calls]/lib{c|m}.a) dann bedient er sich aus dem 
Default, hier also aus avr2 (Multilib-Pfad ist .).

Das erklärt auch den Linkerfehler, und warum der Hack avr2 durch 
avrxmega3 zu ersetzen funktionierte...

von Veit D. (devil-elec)


Lesenswert?

Hallo,

fast richtig.

Das letzte Verzeichnis "avrxmega3" in dem Pfad hier gab es nicht.
1
$INSTALL\avr\lib\avrxmega3\
Das habe ich erst erstellt und die fehlenden Dateien einsortiert - von 
der nativen Toolchain.


Den Pfad hier inkl. letzten Verzeichnis "avrxmega3" gab es.
1
$INSTALL\lib\gcc\avr\9.1.0\avrxmega3
Daran habe ich nichts geändert.
Darin liegt die libgcc.a, libgcov.a und
das short-calls Verzeichnis mit libgcc.a und libgcov.a
Die Dateien mit gleichen Namen unterscheiden sich um ein kByte.


Wenn es an den jetzigen (durch kopieren) nicht 100% passenden Dateien in
1
$INSTALL\avr\lib\avrxmega3\
liegen sollte/könnte, dann kann ich Zak auf seiner Seite anschreiben und 
fragen.

?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich habe mich einmal am Selbstbau einer Toolchain versucht. An einem 
Rechner mit einer Archlinux Distribution.

avr-libc-2.0.0
binutils-2.32
gcc-9.1.0

Laut einer Anleitung aus diesem Forum.
1
PREFIX=$HOME/local/avr/
2
export PREFIX
3
PATH=$PATH:$PREFIX/bin/
4
export PATH
5
../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls
6
make
7
make install
8
cd /home/archi/BuildToolchain/Downloads/avr-libc/
9
./bootstrap
10
cd /home/archi/BuildToolchain/buildLinux/avr-libc/
11
../../Downloads/avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr

Abgestorben bin ich derzeit an der letzten Befehlszeile.
Es erscheint:
> configure: error: Wrong C compiler found; check the PATH!

Was ich mitteilen wollte ist, dass es scheinbar im gcc 9.1 noch keine 
Unterstützung für die neuen µC der megaAVR 0 Serie gibt. Nach dem Befehl
1
./bootstrap
erscheint ja eine Liste was alles "eingebaut" wird/wurde. Ein 
Verzeichnis avrxmega3 gibt es nicht. Ich wollte das einmal testen bevor 
ich bei Zak nachfrage. Scheint als muss man immer Hand anlegen. ?
1
+ rm -rf avr/lib
2
+ ./devtools/gen-avr-lib-tree.sh
3
Generating source directories:
4
  avr/lib/avr2/
5
  avr/lib/avr2/at90s1200
6
  avr/lib/avr2/attiny11
7
  avr/lib/avr2/attiny12
8
  avr/lib/avr2/attiny15
9
  avr/lib/avr2/attiny28
10
  avr/lib/avr2/at90s4414
11
  avr/lib/avr2/at90s4434
12
  avr/lib/avr2/at90s8515
13
  avr/lib/avr2/at90s8535
14
  avr/lib/avr2/at90c8534
15
  avr/lib/avr2/tiny-stack/
16
  avr/lib/avr2/tiny-stack/at90s2313
17
  avr/lib/avr2/tiny-stack/at90s2323
18
  avr/lib/avr2/tiny-stack/at90s2333
19
  avr/lib/avr2/tiny-stack/at90s2343
20
  avr/lib/avr2/tiny-stack/at90s4433
21
  avr/lib/avr2/tiny-stack/attiny22
22
  avr/lib/avr2/tiny-stack/attiny26
23
  avr/lib/avr25/
24
  avr/lib/avr25/at86rf401
25
  avr/lib/avr25/ata5272
26
  avr/lib/avr25/ata6616c
27
  avr/lib/avr25/attiny4313
28
  avr/lib/avr25/attiny43u
29
  avr/lib/avr25/attiny44
30
  avr/lib/avr25/attiny44a
31
  avr/lib/avr25/attiny441
32
  avr/lib/avr25/attiny45
33
  avr/lib/avr25/attiny461
34
  avr/lib/avr25/attiny461a
35
  avr/lib/avr25/attiny48
36
  avr/lib/avr25/attiny828
37
  avr/lib/avr25/attiny84
38
  avr/lib/avr25/attiny84a
39
  avr/lib/avr25/attiny841
40
  avr/lib/avr25/attiny85
41
  avr/lib/avr25/attiny861
42
  avr/lib/avr25/attiny861a
43
  avr/lib/avr25/attiny87
44
  avr/lib/avr25/attiny88
45
  avr/lib/avr25/tiny-stack/
46
  avr/lib/avr25/tiny-stack/attiny13
47
  avr/lib/avr25/tiny-stack/attiny13a
48
  avr/lib/avr25/tiny-stack/attiny2313
49
  avr/lib/avr25/tiny-stack/attiny2313a
50
  avr/lib/avr25/tiny-stack/attiny24
51
  avr/lib/avr25/tiny-stack/attiny24a
52
  avr/lib/avr25/tiny-stack/attiny25
53
  avr/lib/avr25/tiny-stack/attiny261
54
  avr/lib/avr25/tiny-stack/attiny261a
55
  avr/lib/avr3/
56
  avr/lib/avr3/at43usb355
57
  avr/lib/avr3/at76c711
58
  avr/lib/avr31/
59
  avr/lib/avr31/atmega103
60
  avr/lib/avr31/at43usb320
61
  avr/lib/avr35/
62
  avr/lib/avr35/at90usb82
63
  avr/lib/avr35/at90usb162
64
  avr/lib/avr35/ata5505
65
  avr/lib/avr35/ata6617c
66
  avr/lib/avr35/ata664251
67
  avr/lib/avr35/atmega8u2
68
  avr/lib/avr35/atmega16u2
69
  avr/lib/avr35/atmega32u2
70
  avr/lib/avr35/attiny167
71
  avr/lib/avr35/attiny1634
72
  avr/lib/avr4/
73
  avr/lib/avr4/ata6285
74
  avr/lib/avr4/ata6286
75
  avr/lib/avr4/ata6289
76
  avr/lib/avr4/ata6612c
77
  avr/lib/avr4/atmega48
78
  avr/lib/avr4/atmega48a
79
  avr/lib/avr4/atmega48pa
80
  avr/lib/avr4/atmega48pb
81
  avr/lib/avr4/atmega48p
82
  avr/lib/avr4/atmega8
83
  avr/lib/avr4/atmega8a
84
  avr/lib/avr4/atmega88
85
  avr/lib/avr4/atmega88a
86
  avr/lib/avr4/atmega88p
87
  avr/lib/avr4/atmega88pa
88
  avr/lib/avr4/atmega88pb
89
  avr/lib/avr4/atmega8515
90
  avr/lib/avr4/atmega8535
91
  avr/lib/avr4/atmega8hva
92
  avr/lib/avr4/at90pwm1
93
  avr/lib/avr4/at90pwm2
94
  avr/lib/avr4/at90pwm2b
95
  avr/lib/avr4/at90pwm3
96
  avr/lib/avr4/at90pwm3b
97
  avr/lib/avr4/at90pwm81
98
  avr/lib/avr5/
99
  avr/lib/avr5/at90can32
100
  avr/lib/avr5/at90can64
101
  avr/lib/avr5/at90pwm216
102
  avr/lib/avr5/at90pwm316
103
  avr/lib/avr5/at90pwm161
104
  avr/lib/avr5/at90scr100
105
  avr/lib/avr5/at90usb646
106
  avr/lib/avr5/at90usb647
107
  avr/lib/avr5/at94k
108
  avr/lib/avr5/ata5702m322
109
  avr/lib/avr5/ata5782
110
  avr/lib/avr5/ata5790
111
  avr/lib/avr5/ata5790n
112
  avr/lib/avr5/ata5795
113
  avr/lib/avr5/ata5831
114
  avr/lib/avr5/ata6613c
115
  avr/lib/avr5/ata6614q
116
  avr/lib/avr5/atmega16
117
  avr/lib/avr5/atmega16a
118
  avr/lib/avr5/atmega161
119
  avr/lib/avr5/atmega162
120
  avr/lib/avr5/atmega163
121
  avr/lib/avr5/atmega164a
122
  avr/lib/avr5/atmega164p
123
  avr/lib/avr5/atmega164pa
124
  avr/lib/avr5/atmega165
125
  avr/lib/avr5/atmega165a
126
  avr/lib/avr5/atmega165p
127
  avr/lib/avr5/atmega165pa
128
  avr/lib/avr5/atmega168
129
  avr/lib/avr5/atmega168a
130
  avr/lib/avr5/atmega168p
131
  avr/lib/avr5/atmega168pa
132
  avr/lib/avr5/atmega169
133
  avr/lib/avr5/atmega169a
134
  avr/lib/avr5/atmega169p
135
  avr/lib/avr5/atmega169pa
136
  avr/lib/avr5/atmega16hva
137
  avr/lib/avr5/atmega16hva2
138
  avr/lib/avr5/atmega16hvb
139
  avr/lib/avr5/atmega16hvbrevb
140
  avr/lib/avr5/atmega16m1
141
  avr/lib/avr5/atmega16u4
142
  avr/lib/avr5/atmega32
143
  avr/lib/avr5/atmega32a
144
  avr/lib/avr5/atmega323
145
  avr/lib/avr5/atmega324a
146
  avr/lib/avr5/atmega324p
147
  avr/lib/avr5/atmega324pa
148
  avr/lib/avr5/atmega325
149
  avr/lib/avr5/atmega325a
150
  avr/lib/avr5/atmega325p
151
  avr/lib/avr5/atmega325pa
152
  avr/lib/avr5/atmega3250
153
  avr/lib/avr5/atmega3250a
154
  avr/lib/avr5/atmega3250p
155
  avr/lib/avr5/atmega3250pa
156
  avr/lib/avr5/atmega328
157
  avr/lib/avr5/atmega328p
158
  avr/lib/avr5/atmega329
159
  avr/lib/avr5/atmega329a
160
  avr/lib/avr5/atmega329p
161
  avr/lib/avr5/atmega329pa
162
  avr/lib/avr5/atmega3290
163
  avr/lib/avr5/atmega3290a
164
  avr/lib/avr5/atmega3290p
165
  avr/lib/avr5/atmega3290pa
166
  avr/lib/avr5/atmega32c1
167
  avr/lib/avr5/atmega32hvb
168
  avr/lib/avr5/atmega32hvbrevb
169
  avr/lib/avr5/atmega32m1
170
  avr/lib/avr5/atmega32u4
171
  avr/lib/avr5/atmega32u6
172
  avr/lib/avr5/atmega406
173
  avr/lib/avr5/atmega644rfr2
174
  avr/lib/avr5/atmega64rfr2
175
  avr/lib/avr5/atmega64
176
  avr/lib/avr5/atmega64a
177
  avr/lib/avr5/atmega640
178
  avr/lib/avr5/atmega644
179
  avr/lib/avr5/atmega644a
180
  avr/lib/avr5/atmega644p
181
  avr/lib/avr5/atmega644pa
182
  avr/lib/avr5/atmega645
183
  avr/lib/avr5/atmega645a
184
  avr/lib/avr5/atmega645p
185
  avr/lib/avr5/atmega6450
186
  avr/lib/avr5/atmega6450a
187
  avr/lib/avr5/atmega6450p
188
  avr/lib/avr5/atmega649
189
  avr/lib/avr5/atmega649a
190
  avr/lib/avr5/atmega649p
191
  avr/lib/avr5/atmega6490
192
  avr/lib/avr5/atmega6490a
193
  avr/lib/avr5/atmega6490p
194
  avr/lib/avr5/atmega64c1
195
  avr/lib/avr5/atmega64hve
196
  avr/lib/avr5/atmega64hve2
197
  avr/lib/avr5/atmega64m1
198
  avr/lib/avr5/m3000
199
  avr/lib/avr51/
200
  avr/lib/avr51/atmega128
201
  avr/lib/avr51/atmega128a
202
  avr/lib/avr51/atmega1280
203
  avr/lib/avr51/atmega1281
204
  avr/lib/avr51/atmega1284
205
  avr/lib/avr51/atmega1284p
206
  avr/lib/avr51/atmega128rfa1
207
  avr/lib/avr51/atmega1284rfr2
208
  avr/lib/avr51/atmega128rfr2
209
  avr/lib/avr51/at90can128
210
  avr/lib/avr51/at90usb1286
211
  avr/lib/avr51/at90usb1287
212
  avr/lib/avr6/
213
  avr/lib/avr6/atmega2560
214
  avr/lib/avr6/atmega2561
215
  avr/lib/avr6/atmega2564rfr2
216
  avr/lib/avr6/atmega256rfr2
217
  avr/lib/avrxmega2/
218
  avr/lib/avrxmega2/atxmega8e5
219
  avr/lib/avrxmega2/atxmega16a4
220
  avr/lib/avrxmega2/atxmega16a4u
221
  avr/lib/avrxmega2/atxmega16c4
222
  avr/lib/avrxmega2/atxmega16d4
223
  avr/lib/avrxmega2/atxmega32a4
224
  avr/lib/avrxmega2/atxmega32a4u
225
  avr/lib/avrxmega2/atxmega32c3
226
  avr/lib/avrxmega2/atxmega32c4
227
  avr/lib/avrxmega2/atxmega32d3
228
  avr/lib/avrxmega2/atxmega32d4
229
  avr/lib/avrxmega2/atxmega32e5
230
  avr/lib/avrxmega4/
231
  avr/lib/avrxmega4/atxmega64a3
232
  avr/lib/avrxmega4/atxmega64a3u
233
  avr/lib/avrxmega4/atxmega64a4u
234
  avr/lib/avrxmega4/atxmega64b1
235
  avr/lib/avrxmega4/atxmega64b3
236
  avr/lib/avrxmega4/atxmega64c3
237
  avr/lib/avrxmega4/atxmega64d3
238
  avr/lib/avrxmega4/atxmega64d4
239
  avr/lib/avrxmega5/
240
  avr/lib/avrxmega5/atxmega64a1
241
  avr/lib/avrxmega5/atxmega64a1u
242
  avr/lib/avrxmega6/
243
  avr/lib/avrxmega6/atxmega128a3
244
  avr/lib/avrxmega6/atxmega128a3u
245
  avr/lib/avrxmega6/atxmega128b1
246
  avr/lib/avrxmega6/atxmega128b3
247
  avr/lib/avrxmega6/atxmega128c3
248
  avr/lib/avrxmega6/atxmega128d3
249
  avr/lib/avrxmega6/atxmega128d4
250
  avr/lib/avrxmega6/atxmega192a3
251
  avr/lib/avrxmega6/atxmega192a3u
252
  avr/lib/avrxmega6/atxmega192c3
253
  avr/lib/avrxmega6/atxmega192d3
254
  avr/lib/avrxmega6/atxmega256a3
255
  avr/lib/avrxmega6/atxmega256a3u
256
  avr/lib/avrxmega6/atxmega256a3b
257
  avr/lib/avrxmega6/atxmega256a3bu
258
  avr/lib/avrxmega6/atxmega256c3
259
  avr/lib/avrxmega6/atxmega256d3
260
  avr/lib/avrxmega6/atxmega384c3
261
  avr/lib/avrxmega6/atxmega384d3
262
  avr/lib/avrxmega7/
263
  avr/lib/avrxmega7/atxmega128a1
264
  avr/lib/avrxmega7/atxmega128a1u
265
  avr/lib/avrxmega7/atxmega128a4u
266
  avr/lib/avrtiny/
267
  avr/lib/avrtiny/attiny4
268
  avr/lib/avrtiny/attiny5
269
  avr/lib/avrtiny/attiny9
270
  avr/lib/avrtiny/attiny10
271
  avr/lib/avrtiny/attiny20
272
  avr/lib/avrtiny/attiny40

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> avr-libc-2.0.0

Wie bereits gesagt enthält die Release keinen Support für avrxmega3.  Es 
braucht SVN trunk.

> Laut einer Anleitung aus diesem Forum.
>
> PREFIX=$HOME/local/avr/

Es geht auch ein prefix in HOME, dadurch braucht man kein sudo für 
install, und Aufräumen falls was schiefging ist dann auch einfach: rm 
-rf $INSTALL, evtl. auch rm -rf $BUILD.

Generell ist das Vorgehen folgendes:

Quellen

Q1) download / checkout der Quellen
Q2) (cd $GCC_SOURCE; ./contrib/download_prerequisites)  zum Download der 
Host-Libs GMP, MPFR, MPC, ISL.

Binutils

B0) cd $BUILD/binutils-xxx
B1) $BINUTILS_SOURCE/configure --target=avr --disable-nls 
--disable-werror --prefix=$PREFIX
B2) make
B3) [sudo] make install

Compiler

C0) cd $BUILD/gcc-xxx
C1) $GCC_SOURCE/configure --target=avr --languages=c,c++ --disable-nls 
--with-gnu-as --with-gnu-ld --with-dwarf2 --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --disable-shared --enable-checking=release 
--prefix=$PREFIX
C2) make
C3) [sudo] make install

Libc

L0) (cd $LIBC_SOURCE; ./bootstrap)
L1) cd $BUILD/avrlibc-xxx
L2) $LIBC_SOURCE/configure --host=avr --prefix=$PREFIX
L3) [sudo] make install

Damit hast du eine Toolchain in $PREFIX.  Die kann mit Pfaden verwendet 
werden, oder indem $PREFIX zu PATH hinzugefügt wird.

avr-libc nimmt den Compiler aus --prefix, und wenn da nix gefunden wird 
den aus PATH; es sei denn make wird mit CC=path-to-avr-gcc gestartet.

Sehr zu empfehlen ist, avr-libc mit der Compiler-Version zu generieren, 
mit der die Lib schließlich verwendet /installiert wird.

> configure: error: Wrong C compiler found; check the PATH!

avr-libc braucht zum Compilieren einen avr-gcc, der offenbar nicht 
gefunden wurde (weder in --prefix noch in PATH noch per make CC=...).

> es scheinbar im gcc 9.1 noch keine Unterstützung für die neuen
> µC der megaAVR 0 Serie gibt. Nach dem Befehl
>
> ./bootstrap
>
> erscheint ja eine Liste was alles "eingebaut" wird/wurde.

Das ist die Liste der avr-libc. Diese kann mehr und / oder weniger 
Devices unterstützen als avr-gcc.  avr-gcc unterstützt ein paar XTiny 
aus avrxmega3 wie ATtiny3214.  ATmega4808 wird nicht unterstützt, das 
ist der Grund warum es einen Device-Pack braucht.  Die Unterstützung für 
diese Devices zum GCC hinzuzufügen ist nicht schwer, hat aber noch 
keiner für notwendig erachtet...

Falls ein Canadian Cross generiert werden soll, fügt man am einfachsten 
die nativen (build = host) Cross-Tools in PATH hinzu; zudem braucht man 
Cross-Tools mit --host=x86_64-linux-gnu --target=i686-w64-mingw32, d.h 
einen i686-w64-mingw32-gcc samt Host-Libc unter x86_64-linux-gnu.

Die Schritte für die Generierung sind dann analog, allerdings mit 
anderem --prefix=$INSTALL_MINGW, anderen BUILD-Verzeichnissen und 
--build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=avr.

Sofern bereits generiert, lässt sich avr-libc auch direkt per
1
make install PREFIX=$INSTALL_MINGW

installieren, denn die Libs / Header sind unabhängig von --build.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

ja, der avr-gcc fehlte noch. Aktuell läuft mein Script noch was ich aus 
der Anleitung zusammengebastelt habe. Er baut noch alles zusammen. Das 
möchte ich erstmal nicht unterbrechen. Läuft ohne sudo. Die absoluten 
Pfade im Script muss ich später noch relativ machen.
1
##!/bin/bash
2
3
PREFIX=$HOME/local/avr/
4
export PREFIX
5
PATH=$PATH:$PREFIX/bin/
6
export PATH
7
../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls
8
make
9
make install
10
cd /home/archi/BuildToolchain/Downloads/gcc/
11
./contrib/download_prerequisites
12
cd /home/archi/BuildToolchain/buildLinux/gcc
13
../../Downloads/gcc/configure --prefix=$PREFIX --target=avr \
14
    --enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2
15
make
16
make install
17
cd /home/archi/BuildToolchain/Downloads/avr-libc/
18
./bootstrap
19
cd /home/archi/BuildToolchain/buildLinux/avr-libc/
20
../../Downloads/avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr
21
make
22
make install

bei gleicher Ordnerstruktur wie in der Anleitung
1
$HOME
2
|
3
+ BuildToolchain
4
   |
5
   + Downloads
6
   |   |
7
   |   + binutils
8
   |   + gcc
9
   |   + avr-libc
10
   |
11
   + buildLinux
12
   |   |
13
   |   + binutils
14
   |   + gcc
15
   |   + avr-libc
16
   |
17
   + buildWindows
18
       |
19
       + binutils
20
       + gcc

Wenn ich deine Auflistung hier sehe werde ich das BuildScript nochmal 
überarbeiten müssen.

Weil du das betonst.
> "Sehr zu empfehlen ist, avr-libc mit der Compiler-Version zu generieren,
> mit der die Lib schließlich verwendet /installiert wird."
Ich dachte er nimmt die Richtige automatisch. Wie kann ich das 
sicherstellen?

Wenn das bauen durch ist, ja dann möchte ich daraus noch die 
Windowsversion machen. Ich denke das meinst du mit der kanadischen 
Kreuzung.

Was ich jetzt noch nicht ganz verstanden habe ist. Ist das ein Problem 
für mich das die Unterstützung der "avrxmega3" fehlt und ich das 
Devicepaket benötige/verwende oder nicht? Auf den SVN trunk komme ich 
sicherlich nicht drauf. Ist zur Zeit viel Input für mich.  :-)

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Ist das ein Problem für mich das die Unterstützung der "avrxmega3"
> fehlt und ich das Devicepaket benötige/verwende oder nicht?

Das Device-Pack braut's auf jeden Fall, aber der Support ist eben mehr 
als das.  avr-libc ohne avrxmega3 ist witzlos, es sei denn du willst 
wieder händlisch alles reinkopieren.  Gut, sind nur 4 Dateien und die 
CRTS für die XTinys, aber wenn man schon selbst generiert...

> Auf den SVN trunk komme ich sicherlich nicht drauf.
1
svn co svn://svn.savannah.nongnu.org/avr-libc/trunk [dateiname]

von Veit D. (devil-elec)


Lesenswert?

Hallo,

okay.
Mein Problem ist, ich habe keinen blassen Schimmer was ich mit dem 
"Pfad"
1
svn co svn://svn.savannah.nongnu.org/avr-libc/trunk [dateiname]
anfangen muss. Weder der Browser noch ein ftp Client kann damit etwas 
anfangen.

Edit:
Aha, ich benötige die Software "TortoiseSVN" dafür. Langsam macht es 
Arbeit.  :-)

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Mein Problem ist, ich habe keinen blassen Schimmer was ich mit dem
> "Pfad"
>
> svn co svn://svn.savannah.nongnu.org/avr-libc/trunk [dateiname]
>
> anfangen muss.

Du hast doch Linux? Einfach in einer Shell den Befehl ausführen und die 
avr-libc Quelle landet in dateiname.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

Danke für die Erklärungen. Wenn man weiß wie, ist es es einfach.  :-)
Ich habe einen Windowsrechner und einen Linuxrechner.
Auf letzteren baue ich die Toolchain - geht ja nicht anders.
Der Linuxrechner ist eigentlich für etwas anderes da. Egal.

Muss aber nochmal paar Schritte zurück. Als das bauen vorhin fertig war 
kannte er avr-gcc nicht.
Alles nochmal von vorn, jetzt mit deiner aktuellen Vorgehensweise.

Jetzt habe ich nur diesen Teil gemacht.
1
##!/bin/bash
2
3
PREFIX=$HOME/
4
export PREFIX
5
PATH=$PATH:$PREFIX/bin/
6
export PATH
7
8
# Quellen
9
cd /home/archi/BuildToolchain/Downloads/gcc/
10
./contrib/download_prerequisites
11
12
# Binutils
13
cd /home/archi/BuildToolchain/buildLinux/binutils/
14
../../Downloads/binutils/configure --target=avr --disable-nls 
15
--disable-werror --prefix=$PREFIX
16
make
17
make install


Die letzten make Zeilen.
Keine Rechte für „/usr/local/share/info“ und install Abbruch.
Die PREFIX Pfadangabe hat keinen Einfluss. Bricht immer ab.
Alles ohne sudo.
1
make[4]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/ld“ wird verlassen
2
make[3]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/ld“ wird verlassen
3
make[2]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/ld“ wird verlassen
4
make[1]: Für das Ziel „all-target“ ist nichts zu tun.
5
make[1]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils“ wird verlassen
6
make[1]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils“ wird betreten
7
/bin/sh ../../Downloads/binutils/mkinstalldirs /usr/local /usr/local
8
make[2]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/bfd“ wird betreten
9
make  install-recursive
10
make[3]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/bfd“ wird betreten
11
Making install in doc
12
make[4]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/bfd/doc“ wird betreten
13
 /usr/bin/mkdir -p '/usr/local/share/info'
14
/usr/bin/mkdir: das Verzeichnis „/usr/local/share/info“ kann nicht angelegt werden: Keine Berechtigung
15
make[4]: *** [Makefile:824: install-info-am] Fehler 1
16
make[4]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/bfd/doc“ wird verlassen
17
make[3]: *** [Makefile:1641: install-recursive] Fehler 1
18
make[3]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/bfd“ wird verlassen
19
make[2]: *** [Makefile:1749: install] Fehler 2
20
make[2]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils/bfd“ wird verlassen
21
make[1]: *** [Makefile:2757: install-bfd] Fehler 2
22
make[1]: Verzeichnis „/home/archi/BuildToolchain/buildLinux/binutils“ wird verlassen
23
make: *** [Makefile:2224: install] Fehler 2

Ohne sudo wird es wohl nicht funktionieren?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> PREFIX=$HOME/

Arrgh.  Damit installiert er in HOME, und du bekommst da zig 
Verzeichnisse avr, lib, bin, include, ... Als ich meinte, prefix in 
HOME, dann naturlich in einem (noch) nicht existierenden Verzeichnis! 
$HOME/local/avr/ ist schon ok.

> /usr/bin/mkdir: das Verzeichnis „/usr/local/share/info“ kann nicht
> angelegt werden: Keine Berechtigung

Hast du da noch überreste von einem alten Build / Configure?  Die Doks 
sollten in $PREFIX/share installiert werden, es sei denn du hast 
--docdir oder --datarootdir oder sowas gesetzt.

Versuch mal, das Build-Verzeichnis komplett, bevor du wieder (mit 
anderen Flags) configure startest (oder anderes, leeres Build-Dir 
verwenden).

Bist du sicher, dass $PREFIX das enthält, was du denkst? Mach mal "set 
+x" im Skript, damit du die ausgeführten Kommandos siehst mit allen $xyz 
aufgelöst.

Wie sieht denn config.log aus?

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

> Ohne sudo wird es wohl nicht funktionieren?

Doch, muss.  Irgendo hast du noch nen Fehler oder Altlasten.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

wenn ich die Baustruktur komplett neu erstelle
1
$HOME
2
|
3
+ BuildToolchain
4
   |
5
   + Downloads
6
   |   |
7
   |   + binutils
8
   |   + gcc
9
   |   + avr-libc
10
   |
11
   + buildLinux
12
   |   |
13
   |   + binutils
14
   |   + gcc
15
   |   + avr-libc
16
   |
17
   + buildWindows
18
       |
19
       + binutils
20
       + gcc

dann sollte das mit PREFIX HOME funktionieren?
Wo können noch Altlasten versteckt sein?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Wenn du ein configure in einem Build-Verzeichnis macht, das zuvor mit 
anderen configure-Optionen benutzt wurde.  Da würd ich nicht drauf 
wetten, dass alles komplett neu generiert wird.

Was sagt denn config.log von binutils?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

mit config.log kann ich aktuell nicht dienen. Habe alles wieder 
gelöscht.
Ich hatte dich falsch verstanden mit dem PREFIX.
Ich habe unter meinem home Verzeichnis nur ein verstecktes 
.local/share/...

Ich ändere das PREFIX wieder auf $HOME/local/avr/
und
lege ein Verzeichnis local/avr selbst an
Dann versuche ich alles erneut.
Soweit korrekt?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

du meinst "set -x" ?

Aktuell läuft ein neuer Baudurchgang ohne sudo, bin guter Hoffnung ... 
:-)

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Soweit korrekt?

Schwer zu sagen via Draht...

Install-Verzeichnis brauchst nicht von Hand anzulegen, sollte nur leer 
sein (bzw. bei GCC-Installation nicht mahe als Binutils enthalten etc).

Wenn irgendwas nich so läuft wie erwartet wir mal nen Blick ind 
config.log ob alle Werte richtig bestimmt wurden.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

mühsam ernährt sich das Eichhörnchen.  :-)

Das Script lief jetzt durch. Um das manuelle anlegen von 
$HOME/local/avr/ kam ich nicht drum herum. Ich hatte das Verzeichnis 
während meiner unzähligen Versuche nie gesehen.
1
set -x
2
3
PREFIX=$HOME/local/avr/
4
export PREFIX
5
PATH=$PATH:$PREFIX/bin/
6
export PATH
7
8
# 
9
> cd BuildToolchain/Downloads/gcc
10
> ./contrib/download_prerequisites
11
12
# Binutils
13
> cd /home/archi/BuildToolchain/buildLinux/binutils
14
> ../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls --disable-werror --prefix=$PREFIX
15
> make
16
> make install
17
18
# Compiler
19
> cd /home/archi/BuildToolchain/buildLinux/gcc
20
> ../../Downloads/gcc/configure --prefix=$PREFIX --target=avr --enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2 --build=x86_64-linux-gnu --host=x86_64-linux-gnu --disable-shared --enable-checking=release
21
> make
22
> make install
23
24
# Libc
25
> cd /home/archi/BuildToolchain/Downloads/avr-libc
26
> ./bootstrap
27
> cd /home/archi/BuildToolchain/buildLinux/avr-libc
28
> ../../Downloads/avr-libc/configure --host=avr --prefix=$PREFIX
29
> make
30
> make install

Erster Test mit
> avr-gcc --version
klappt auch.

Beim Logfile bitte ich dich einmal drüberzuschauen. Ich weiß nicht was 
wichtig ist. Wenn das okay ist würde ich dann weiter machen mit der 
Windowsversion.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

habe aus meiner Sicht alles fehlende nachinstalliert um die 
Windowsvariante zu bauen, jedoch bricht er immer wieder ab. Mein Script 
für die 32bit Windows Variante.
1
##!/bin/bash
2
3
JOBCOUNT=4
4
5
set -x
6
7
PREFIX=$HOME/local/avr4win/
8
export PREFIX
9
PATH=$PATH:$PREFIX/bin/
10
export PATH
11
12
#  ist schon vorhanden
13
# cd BuildToolchain/Downloads/gcc
14
# ./contrib/download_prerequisites
15
16
# Binutils
17
cd /home/archi/BuildToolchain/buildWindows/binutils
18
../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls --disable-werror --prefix=$PREFIX
19
make -j $JOBCOUNT
20
make install
21
22
# Compiler
23
cd /home/archi/BuildToolchain/buildWindows/gcc
24
../../Downloads/gcc/configure --prefix=$PREFIX --target=avr --enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2 --build=i686-linux-gnu --host=i686-w64-mingw32 --disable-shared --enable-checking=release
25
make -j $JOBCOUNT
26
make install
27
28
# Libc
29
cd /home/archi/BuildToolchain/Downloads/avr-libc
30
./bootstrap
31
cd /home/archi/BuildToolchain/buildWindows/avr-libc
32
../../Downloads/avr-libc/configure --host=avr --prefix=$PREFIX
33
make -j $JOBCOUNT
34
make install


Die letzten Zeilen aus dem Terminal.
1
+ automake --foreign --add-missing --copy
2
+ cd /home/archi/BuildToolchain/buildWindows/avr-libc
3
+ ../../Downloads/avr-libc/configure --host=avr --prefix=/home/archi/local/avr4win/
4
checking build system type... x86_64-pc-linux-gnu
5
checking host system type... avr-unknown-none
6
checking if configuring for cross compile... yes
7
checking if target host is avr... yes
8
checking for a BSD-compatible install... /usr/bin/install -c
9
checking whether build environment is sane... yes
10
checking for avr-strip... avr-strip
11
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
12
checking for gawk... gawk
13
checking whether make sets $(MAKE)... yes
14
checking whether make supports nested variables... yes
15
checking for avr-gcc... no
16
checking for gcc... gcc
17
checking whether the C compiler works... yes
18
checking for C compiler default output file name... a.out
19
checking for suffix of executables... 
20
checking whether we are cross compiling... no
21
checking for suffix of object files... o
22
checking whether we are using the GNU C compiler... yes
23
checking whether gcc accepts -g... yes
24
checking for gcc option to accept ISO C89... none needed
25
checking whether gcc understands -c and -o together... yes
26
checking whether make supports the include directive... yes (GNU style)
27
checking dependency style of gcc... gcc3
28
checking for avr-as... avr-as
29
checking dependency style of gcc... gcc3
30
checking for avr-ranlib... avr-ranlib
31
checking for avr-ar... avr-ar
32
configure: error: Wrong C compiler found; check the PATH!
33
+ make -j 4
34
make: *** Es wurden keine Ziele angegeben und keine „make“-Steuerdatei gefunden.  Schluss.
35
+ make install
36
make: *** Keine Regel, um „install“ zu erstellen.  Schluss.

Logfiles hängen dran. Kannst du mir bitte sagen wo es klemmt?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:

> PATH=$PATH:$PREFIX/bin/

Nicht sonderlich sinnvoll, da die mingw32-Binaries nicht unter Linux 
ausführbar sind :-)

Wichtig ist, dass die beiden Cross-Toolchains (linux->mingw32 für 
Binutils+GCC, linux->avr für avr-libc) im Pfad sind.

> # Binutils
> cd /home/archi/BuildToolchain/buildWindows/binutils
> ../../Downloads/binutils/configure --prefix=$PREFIX --target=avr
> --disable-nls --disable-werror --prefix=$PREFIX

Hier brauchst du --build=i686-linux-gnu --host=i686-w64-mingw32, 
ansonsten bekommst du native Cross-Tools (linux->avr) anstatt canadian 
(mingw32->avr generiert unter linux).

Sieht man auch im Binutils config.log:
1
## ----------- ##
2
## Core tests. ##
3
## ----------- ##
4
5
configure:2336: checking build system type
6
configure:2350: result: x86_64-pc-linux-gnu
7
configure:2397: checking host system type
8
configure:2410: result: x86_64-pc-linux-gnu
9
configure:2430: checking target system type
10
configure:2443: result: avr-unknown-none
11
...
12
configure:4466: checking whether we are cross compiling
13
...
14
configure:4477: result: no

Und --prefix ist doppelt.


> # Libc
> ...
> checking for avr-gcc... no

Wie gesagt muss avr-gcc in PATH sein oder per make CC= angegeben werden. 
Und --prefix hilft nix, weil avr-gcc.exe nicht ausführbar ist.

Aber es geht auch viel einfacher und schneller:

Johann L. schrieb:
> Sofern bereits generiert, lässt sich avr-libc auch direkt per
1
> make install PREFIX=$INSTALL_MINGW
> installieren, denn die Libs / Header sind unabhängig von --build.

Nächster Schritt ist also mingw32 INSTALL und ming32 BUILD Verzeichnisse 
zu löschen und wieder von vorne anzufangen mit den mingw32 avr-Tools.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Noch 2 Anmerkungen:

Mit make install-strip für Binutils / GCC bekommt man kleinere Binaries, 
spart Speicherplatz und Ladezeit.

Laut http://gcc.gnu.org/PR91189 erzeugt avr-gxx v9 merklich größeren 
Code als v8.  Wenn's nicht den neuesten C++ Schnickes braucht, kann die 
v8.3 durchaus angesagt sein.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

es ist leider für mich sehr sehr schwer das was du schreibst 
nachzuvollziehen und umzusetzen. Ich kann mit den Stichpunkten nichts 
konkret anfangen.
Anfangs blieb alles analog zum bauen der LinuxToolchain. Jetzt muss ich 
dem noch extra einen Pfade angeben. Ich weiß gar nicht wie. Weil die 
sind ja da.

Auch die Befehlszeilen für Windows von hier klappen nicht. 
https://www.mikrocontroller.net/articles/AVR-GCC

Ich drehe mich den ganzen Tag im Kreis.

Wenn ich das Ganze vorher weglassen kann, dann würde das laut meiner 
Interpretation so aussehen.
1
##!/bin/bash
2
3
set -x
4
5
INSTALL_MINGW=$HOME/local/avr4win/
6
export PREFIX
7
PATH=$PATH:/home/archi/BuildToolchain/Downsloads/gcc
8
export PATH
9
10
make install PREFIX=$INSTALL_MINGW

Nur was soll hier aufgerufen werden?
Womit soll hier gebaut werden?
Wo sind denn die ganzen Optionen i686 hin?
Alle plötzlich überflüssig?
Ich verstehe es nicht.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

in

/home/archi/BuildToolchain/Downloads/gcc

gibts ja den INSTALL Ordner
Muss ich den rüberkopieren?

Muss ich nun die binutils und gcc mit den i686 mingw Optionen neu 
kompilieren oder nicht?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

wenn ich das ausführen lasse
1
##!/bin/bash
2
3
set -x
4
5
PREFIX=$HOME/local/avr/
6
export PREFIX
7
PATH=$PATH:$PREFIX/bin/
8
export PATH
9
10
avr-gcc --version

erhalte ich folgende korrekte Ausgabe
1
+ PREFIX=/home/archi/local/avr/
2
+ export PREFIX
3
+ PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/archi/local/avr//bin/
4
+ export PATH
5
+ avr-gcc --version
6
avr-gcc (GCC) 9.1.0
7
Copyright (C) 2019 Free Software Foundation, Inc.
8
This is free software; see the source for copying conditions.  There is NO
9
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Bedeutet für mich der avr-gcc ist generell verfügbar.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

--host und --build für die mingw32-Binutils fehlten.

Also

* mingw32-Install sowie mingw32-Build löschen.

* i686-w64-mingw32-gcc muss im PATH sein.

* Zur Generierung von avr-gcc.exe muss avr-gcc im PATH sein (da 
Target-Libs wie libgcc generiert werden sollen).

* Binutils für mingw mit richtigem --host --build generieren und 
installieren.

* avr-gcc.exe generieren und installieren.  Ob bei der Generierung 
deines avr-gcc.exe, der bei configure die falschen Binutils vorfand, 
alles richtig lief, weiß ich nicht.  Sicher bist du mit tabula rasa für 
avr-gcc.exe.

* avr-libc hast du schon generiert für die linux Tools, also wechsle ins 
Build-Verzeichnis der avr-libc und dann

> make install PREFIX=$INSTALL_MINGW

Wenn du avr-libc Build gelöscht hast, selber Schuld :-) Dann musst du 
avr-libc neu generieren.


> [code]
> ##!/bin/bash
>
> set -x
>
> INSTALL_MINGW=$HOME/local/avr4win/
> export PREFIX

Vermutlich export INSTALL_MINGW.

> PATH=$PATH:/home/archi/BuildToolchain/Downsloads/gcc
> export PATH

Die Quellen brauchst du nicht im Pfad.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

gelöscht habe ich nichts. Das ist alles da. Auch eine avr-gcc.exe

Bevor ich mich aber weiter am Bau der Windows Toolchain abracker muss 
ich was anderes in die Runde werfen. Ein Geistesblitz  :-)  sagte mir 
guckst doch mal in der Linux Toolchain nach ob die neuen ATmegas 
überhaupt vorhanden sind. Was soll sagen. Sind sie nicht.

Es gibt in der bisher erzeugten Linux Toolchain keine specs Dateien für 
den ATmega4808 bzw. 4809.

Es gibt in:
/home/archi/local/avr/lib/gcc/avr/9.1.0/device-specs
eine Datei namens: specs-avrxmega3
aber keine Dateien Bspw. namens "specs-atmega4808", nur wieder von allen 
anderen µC.

jedoch gibt es einen Ordner:
/home/archi/local/avr/lib/gcc/avr/9.1.0/arvxmega3
mit Unterordner "short-calls"
und 2 Dateien
libgcc.a und libgcov.a

Das wars. Ich habe zwar wenig Ahnung aber das sagt mir das ist noch 
nicht das was ich/wir bauen wollten.

Ging was mit dem SVN schief?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Das ist alles da. Auch eine avr-gcc.exe

Würd mich aber wundern wenn da auch avr-as.exe, avr-ld.exe etc. wären.

> Es gibt in der bisher erzeugten Linux Toolchain keine specs Dateien für
> den ATmega4808 bzw. 4809.

Siehe

Johann L. schrieb:
> Der Compiler kann die Specs für ATmega4808 (noch) nicht
> generieren, die Dateien sind also Handarbeit.

Von avr-libc kommen nur libc.a, libm.a, Device-libs, crt*.o und io*.h.

.../lib/gcc/$target/$version/ enthält Sachen vom Compiler wie libgcc.

.../$target/lib/ enthält Sachen, die nicht vom Compiler sind (libc, 
crt<device>.o, lib<device>.a, ldscripts, ...)

> Ging was mit dem SVN schief?

Sieht nicht danach aus.  Dein config.log der avr-libc babbelt auch was 
von avrxmega3.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

das ist der Inhalt von
cd /home/archi/local/avr/bin
also von der gebauten Linux Toolchain.
Alles da würde ich sagen.
1
-rwxr-xr-x 1 archi users 4889352 25. Jul 16:25 avr-addr2line
2
-rwxr-xr-x 2 archi users 5122864 25. Jul 16:25 avr-ar
3
-rwxr-xr-x 2 archi users 7145664 25. Jul 16:25 avr-as
4
-rwxr-xr-x 2 archi users 5807648 25. Jul 16:36 avr-c++
5
-rwxr-xr-x 1 archi users 4838952 25. Jul 16:25 avr-c++filt
6
-rwxr-xr-x 1 archi users 5803944 25. Jul 16:36 avr-cpp
7
-rwxr-xr-x 1 archi users  271824 25. Jul 16:25 avr-elfedit
8
-rwxr-xr-x 2 archi users 5807648 25. Jul 16:36 avr-g++
9
-rwxr-xr-x 2 archi users 5786200 25. Jul 16:36 avr-gcc
10
-rwxr-xr-x 2 archi users 5786200 25. Jul 16:36 avr-gcc-9.1.0
11
-rwxr-xr-x 1 archi users  174336 25. Jul 16:36 avr-gcc-ar
12
-rwxr-xr-x 1 archi users  174240 25. Jul 16:36 avr-gcc-nm
13
-rwxr-xr-x 1 archi users  174256 25. Jul 16:36 avr-gcc-ranlib
14
-rwxr-xr-x 1 archi users 5234360 25. Jul 16:36 avr-gcov
15
-rwxr-xr-x 1 archi users 3425480 25. Jul 16:36 avr-gcov-dump
16
-rwxr-xr-x 1 archi users 3673048 25. Jul 16:36 avr-gcov-tool
17
-rwxr-xr-x 1 archi users 5556352 25. Jul 16:25 avr-gprof
18
-rwxr-xr-x 4 archi users 8286832 25. Jul 16:25 avr-ld
19
-rwxr-xr-x 4 archi users 8286832 25. Jul 16:25 avr-ld.bfd
20
-rwxr-xr-x 1 archi users    1761 25. Jul 16:39 avr-man
21
-rwxr-xr-x 2 archi users 4938208 25. Jul 16:25 avr-nm
22
-rwxr-xr-x 2 archi users 5792952 25. Jul 16:25 avr-objcopy
23
-rwxr-xr-x 2 archi users 6701016 25. Jul 16:25 avr-objdump
24
-rwxr-xr-x 2 archi users 5122896 25. Jul 16:25 avr-ranlib
25
-rwxr-xr-x 2 archi users 2117928 25. Jul 16:25 avr-readelf
26
-rwxr-xr-x 1 archi users 4876464 25. Jul 16:25 avr-size
27
-rwxr-xr-x 1 archi users 4876320 25. Jul 16:25 avr-strings
28
-rwxr-xr-x 2 archi users 5792952 25. Jul 16:25 avr-strip

Lasse ich im Dateimanager nach "crt" oder "crtatmega4" suchen
gibts keine für 4808 zum Bsp. Nix.
Alles ab /avr/lib/  und tiefer

Auch eine io4808 gibts nichts. (avr/include/avr)

Habe auch nochmal im runtergeladenen SVN Verzeichnis geschaut.
Hier ist auch weit und breit nichts für die neuen µC zu sehen.

Irgendwas stimmt hier nicht. Lade du einmal das SVN runter und schau 
bitte nach.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Hallo,
>
> das ist der Inhalt von
> cd /home/archi/local/avr/bin
> also von der gebauten Linux Toolchain.
> Alles da würde ich sagen.

Es geht doch um /home/archi/local/avr4win/bin ?  Ist da auch alles da?

> Habe auch nochmal im runtergeladenen SVN Verzeichnis geschaut.
> Hier ist auch weit und breit nichts für die neuen µC zu sehen.

Da ist auch nix zu sehen weil's da nix gibt.  Was SVN trunk hat ist die 
Multilib-Unterstützung für avrxmega3 und avrxmega3/short-calls, also 2 
Verzeichnisse mit je libm.a und libc.a.  Und libm.a war doch genau das, 
was du brauchtest weil deren Fehlen Probleme machte?

Für die Devices brauchst du Device-Packs.  Das einzige was da ist sind 
die Specs für die ATtiny in avrxmega3 die dir nicht helfen (außer als 
Vorlage, die du aber auch nicht brauchst da du Device-Packs schon hast).

Häng mal das specs-atmega480x an.  Dann kann ich dir sagen, ob das auf 
v8+ passt.

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

okay, nochmal ganz langsam.
Wegen den specs Dateien usw. - alles klar. Hatte den Überblick verloren.

Das Verzeichnis
/home/archi/local/avr4win/
ist komplett leer. Weil ich bisher nicht bauen konnte.
Das ist ja mein Problem bis jetzt.

Die specs Datei ist aus der AS7 Installation auf dem Windowsrechner.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Das Verzeichnis /home/archi/local/avr4win/ ist komplett leer.

Ich hachte für Binutils und Gcc hätte es funktioniert? (auch wenn 
Binutils falsche --host und --build hatte), und erst bei libc wäre ein 
Fehler aufgetreten?

specs sieht soweit gut aus.
1
%rename link old_link
2
3
*link:
4
  %(old_link)--defsym=__RODATA_PM_OFFSET__=0x4000

Keine Ahnung, warum die diesen Hack verwenden; jedenfalls klärt es das 
ominöse "rename spec link to old_link" von oben.  Hätte man auch 
einfacher haben können mit
1
*link_arch:
2
  %{mmcu=*:-m%*} --defsym=__RODATA_PM_OFFSET__=0x4000

Aber egal.  Was jedoch fehlt für v8+ (und nur da) ist
1
*asm_gccisr:
2
  %{!mno-gas-isr-prologues: -mgcc-isr}
was obiges "pseudo instruction `__gcc_isr' not supported" auslöste.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

dann hast du mich leider falsch verstanden. Bisher konnte ich nur die 
LinuxToolchain bauen. Mehr nicht. Ich vermute ein Problem mit der mingw 
Installation auf dem Archrechner. Ich konnte nur irgendwas mit mingw-w64 
installieren und da gab es schon Paket-Abhängkeitsfehlermeldungen. Ich 
dachte aber wird schon passen. Eine andere Auswahl/Möglichkeit 
habe/hatte ich sowieso nicht.

Weil das hier geht nicht - sollte aber doch nun eigentlich 
funktionieren?
1
#!/bin/bash
2
3
set -x
4
5
PREFIX=$HOME/local/avr4win/
6
export PREFIX
7
8
# Binutils
9
cd /home/archi/BuildToolchain/buildWindows/binutils
10
../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --build=i686-linux-gnu ---host=i686-w64-mingw32 --disable-nls --disable-werror
11
make
12
make install

Ich erhalte immer
1
+ PREFIX=/home/archi/local/avr4win/
2
+ export PREFIX
3
+ cd /home/archi/BuildToolchain/buildWindows/binutils
4
+ ../../Downloads/binutils/configure --prefix=/home/archi/local/avr4win/ --target=avr --build=i686-linux-gnu ---host=i686-w64-mingw32 --disable-nls --disable-werror
5
configure: error: unrecognized option: `---host=i686-w64-mingw32'
6
Try `../../Downloads/binutils/configure --help' for more information
7
+ make
8
make: *** Es wurden keine Ziele angegeben und keine „make“-Steuerdatei gefunden.  Schluss.
9
+ make install
10
make: *** Keine Regel, um „install“ zu erstellen.  Schluss.

Antergos wird derzeit umgebaut zu EndeavourOS. Fremde Paketquellen sind 
schon eine Weile abgeschalten. Bis EndeavourOS fertig ist wird es noch 
eine Weile dauern. Ich werde wohl alles nochmal in einer VM mit Ubuntu 
machen müssen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> configure: error: unrecognized option: `---host=i686-w64-mingw32'

--host=i686-w64-mingw32

Was zählt ist i.d.R. die erste Fehlermeldung.

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Menno, so viele Tippfehler kann man doch gar nicht machen. Liegt 
vielleicht auch daran das ich am laufenden Band korrigiere und probiere. 
Aber trotz Korrektur will es nicht.

Ich sehe eine Warnung
configure: WARNING: using cross tools not prefixed with host triplet
und am Ende immer
checking for library containing strerror... configure: usw.

Das kann doch jetzt nicht mehr Script liegen?
Ich mach seit Tagen nichts anderes als Befehlszeilen zusammenzusetzen.

Edit: Ausgabe lieber als Textanhang.   :-)

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. [config.log] schrieb:
> checking for i686-w64-mingw32-gcc... no
> checking for gcc... gcc
> configure: WARNING: using cross tools not prefixed with host triplet
> [...]
> checking for i686-w64-mingw32-ar... no
> checking for i686-w64-mingw32-as... no
> checking for i686-w64-mingw32-dlltool... no
> checking for i686-w64-mingw32-ld... no
> [...]
> checking for avr-cc... no
> checking for avr-gcc... no
> checking for avr-c++... no

Siehe

Johann L. schrieb:
> Wichtig ist, dass die beiden Cross-Toolchains (linux->mingw32 für
> Binutils+GCC, linux->avr für avr-libc) im Pfad sind.

Ich tipps mir die Finger wund und du liest es nicht mal :-/

Ohne i686-w64-mingw32-gcc brauch du kein configure anzufangen (wobei 
linux->avr auch für GCC gebraucht wird).

Konkret.  Was funktionieren muss ohne Fehler ist
1
i686-w64-mingw32-gcc --version
1
avr-gcc --version

wobei avr-gcc Version die gleiche sein muss, für welche du einen 
Canadian Cross erstellen willst, hier also v9.1.

Du kannst auch mal versuchen, ein kleines Hallo-Welt.exe mit 
i686-w64-mingw32-gcc zu generieren und unter Windows auszuführen.  Wenn 
das schon nicht geht ist die Baustelle ersma die linux->mingw 
Cross-Toolchain.

Falls w64 nicht funktioniert tut's auch eine w32 Toolchain, ist 
vielleicht unter Win64 minimal ineffizienter als eine w32, aber das tut 
nix.  Vielleich ist w32 einfacher aufzusetzen.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

also ich will ja nichts sagen, aber mehr wie lesen und schreiben kann 
ich auch nicht. Tut mir leid.

Also nochmal.
avr-gcc --version
funktioniert nur mit Script und Pfadangabe.
mingw Versionsabfrage funktioniert auch damit nicht.

Im nackten Terminal funktioniert das wie gesagt nicht.
> avr-gcc --version

Script:
1
##!/bin/bash
2
3
PREFIX=$HOME/local/avr
4
export PREFIX
5
PATH=$PATH:$PREFIX/bin
6
export PATH
7
8
avr-gcc --version
9
i686-w64-mingw32-gcc --version

Ausgabe:
1
vr-gcc (GCC) 9.1.0
2
Copyright (C) 2019 Free Software Foundation, Inc.
3
This is free software; see the source for copying conditions.  There is NO
4
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
5
6
buildTest.sh: Zeile 9: i686-w64-mingw32-gcc: Kommando nicht gefunden.

Das heißt für mich das mingw nicht wie erforderlich installiert ist.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich habe die Ubuntu VM mittlerweile eingerichtet.
Nachträglich installiert habe ich
> sudo apt-get install aptitude
> sudo aptitude install build-essential
> sudo aptitude install mingw-w64
> sudo apt install subversion
und
> svn co svn://svn.savannah.nongnu.org/avr-libc/trunk neueAvrLibc

Allerdings kann er die avr-libc nicht bauen.
Irgendwie kann er entweder keine configure erstellen oder er findet 
keine weil es keine gibt.

Script:
1
##!/bin/bash
2
3
set -x
4
5
PREFIX=$HOME/local/avr/
6
export PREFIX
7
PATH=$PATH:$PREFIX/bin/
8
export PATH
9
10
cd /home/ubuntixer/toolchain/downloads/avr-libc
11
./bootstrap
12
../../downloads/avr-libc/configure --host=avr --prefix=$PREFIX
13
make
14
make install

Ausgabe:
1
  avr/lib/avrtiny/attiny40
2
+ rm -rf autom4te.cache
3
+ aclocal
4
./bootstrap: 25: ./bootstrap: aclocal: not found
5
+ autoheader
6
./bootstrap: 26: ./bootstrap: autoheader: not found
7
+ autoconf
8
./bootstrap: 27: ./bootstrap: autoconf: not found
9
+ automake --foreign --add-missing --copy
10
./bootstrap: 28: ./bootstrap: automake: not found
11
+ ../../downloads/avr-libc/configure --host=avr --prefix=/home/ubuntixer/local/avr/
12
buildLinux.sh: 37: buildLinux.sh: ../../downloads/avr-libc/configure: not found
13
+ make -j 4
14
make: *** Es wurden keine Ziele angegeben und keine „make“-Steuerdatei gefunden.  Schluss.
15
+ make install
16
make: *** Keine Regel, um „install“ zu erstellen.  Schluss.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

im Download der avr-libc vom svn trunk fehlt die configure Datei.
Die ist in der offiziellen avr-libc 2.0.0 enthalten.
Liegt das daran?
Ich wundere mich jedoch das ich auf dem Archrechner die LinuxToolchain 
bauen konnte. Aber das ist nun mittlerweile 2 Tage her.

von Johann J. (johannjohanson)


Lesenswert?

Veit D. schrieb:
> \

Fällt Dir die Richtung des Schrägstriches (auch Backslash genannt :-)) 
auf?

Veit D. schrieb:
> c:/users/devil/documents/atmel
> studio/7.0/toolchain/avr-gcc-9.1.0_mingw32/bin/../lib/gcc/avr/9.1.0/../.
> ./../../avr/lib\libm.a

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Was möchtest du mir damit sagen?
Die Datei libm.a befindet sich im dem Verzeichnis.
C:\Users\devil\Documents\Atmel 
Studio\7.0\toolchain\avr-gcc-9.1.0_mingw32\avr\lib

und sie gibt es noch in paar anderen Verzeichnissen.

von Johann J. (johannjohanson)


Lesenswert?

Veit D. schrieb:
> Was möchtest du mir damit sagen?

Das Schrägstriche in Pfaden nicht willkürlich rechts/\links verwendet 
werden können.

Findest Du in der AVR-GCC-Toolchain 9.1 irgendeine Datei mit Namen 
"*4808*.*" ? Falls nicht, suche mal nach z.B. "*2560*.*" und schau, 
welche Dateien gefunden werden.


Mittlerweile habe ich das Atmel Studio 7.0 in einer Windows 10 VM frisch 
installiert - ein leeres ATMega4808-Projekt lässt sich problemlos 
kompilieren.

Wenn Du eine andere Toolchain nutzen willst, dann sollte die den 
verwendeten Prozessor auch unterstützen (können) - sonst wird das 
nichts, wie Du siehst.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Weiß immer noch nicht was du mir damit sagen möchtest.
Außerdem wo hast das jetzt her?
Wie kommst du darauf?
Du redest jetzt wirklich vom Windowsrecher?

In meiner aktuellen toolchain mit den kopierten Dateien finde ich ich je 
4 Dateien.

crtatmega4808.o
iom4808.h
libatmega4808.a
specs-atmega4808

Analog zum 2560er.

Im Backup meiner Toolchain's (vor der Kopieraktion) findet sich nur eine 
Datei iom4808.h

von Johann J. (johannjohanson)


Lesenswert?

Veit D. schrieb:
> Du redest jetzt wirklich vom Windowsrecher?
>
> In meiner aktuellen toolchain mit den kopierten Dateien finde ich ich je
> 4 Dateien.

Ja.

Woher hast Du die 9.1 Toolchain - poste bitte den Link. Ich kenne Deine 
"aktuelle Toolchain" nicht, da ich sie nicht habe.

In der AVR-GCC-9.1-Toolchain von z.B. 
http://blog.zakkemble.net/avr-gcc-builds/ gibt es keine 
"*4808*.*"-Dateien.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

meine Toolchain ist von Zak Kemble.
http://blog.zakkemble.net/avr-gcc-builds/

Kann sein das ich die eine Datei iom4808.h vor langer langer Zeit für 
die ersten Selbstversuche kopiert hatte. Muss wirklich schon sehr lange 
her sein. Eine andere Erklärung habe ich dafür nicht.

Nur das die Toolchain von Zak einen ATmega4808 u.a. neue nicht enthält 
hatten wir doch schon vor paar Tagen festgestellt. Deswegen hatte ich ja 
vor paar Tagen auch die fehlenden Dateien vom Atmel Devicepack kopiert, 
was ja erstmal funktioniert mit Atmel Studio. Nur das paar Dateien davon 
eben nicht vom 9.1.er gcc stammen. Hast du mir erklärt. Deswegen baue 
ich mir ja eine eigene Toolchain. Bzw. möchte ich mir bauen.  :-)

Mich wundert jetzt das du dich wunderst das die fehlen.
Bin jetzt irritiert.

von Johann J. (johannjohanson)


Lesenswert?

Veit D. schrieb:
> Mich wundert jetzt das du dich wunderst das die fehlen.
> Bin jetzt irritiert.

Meinst Du im Ernst, dass es genügt ein paar Dateien zu kopieren damit 
der MC in der AVR-GCC 9.1 Toolchain unterstützt wird?

Mal so, als Denkansatz, es gibt vor-compilierte Librarys ...

: Bearbeitet durch User
von Johann J. (johannjohanson)


Lesenswert?

Veit D. schrieb:
> Deswegen baue
> ich mir ja eine eigene Toolchain. Bzw. möchte ich mir bauen.  :-)

Frage mal bei Jörg Wunsch (Moderator) nach, vielleicht braucht er noch 
Unterstützung :-)

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

?

Nachdem kopieren von den fehlenden Dateien aus dem Atmel Devicepack in 
die 9.1er  Toolchain konnte ich ein kleines sinnloses Programm 
kompilieren in Atmel Studio. Hatte ich vor paar Tagen mitgeteilt.

Aktueller Stand in der Ubuntu VM ist.
Linux Toolchain ist gebaut.
Bei der Win32 Version konnte ich bis jetzt nur das binutils bauen.
gcc weigert sich.

Er bricht ab mit
1
Makefile:4405: recipe for target 'install-gcc' failed
2
make[1]: *** [install-gcc] Error 2
3
make[1]: Verzeichnis „/home/ubuntixer/toolchain/buildWindows/gcc“ wird verlassen
4
Makefile:2335: recipe for target 'install' failed
5
make: *** [install] Error 2

Script
1
##!/bin/bash
2
3
set -x
4
5
# For optimum compile time this should generally be set to the number of CPU cores your machine has
6
JOBCOUNT=4
7
8
rm -rf /home/ubuntixer/toolchain/buildWindows/gcc/*
9
10
PREFIX=$HOME/local/avrWindows32/
11
export PREFIX
12
PATH=$PATH:$PREFIX/bin/
13
export PATH
14
15
# GCC
16
cd /home/ubuntixer/toolchain/buildWindows/gcc
17
../../downloads/gcc/configure --prefix=$PREFIX --target=avr --disable-nls --host=i686-w64-mingw32 --build=i686-linux-gnu --enable-languages=c,c++,lto --with-gnu-as --with-gnu-ld --disable-shared --with-dwarf2
18
make -j $JOBCOUNT
19
make install

Ausgabe hängt dran.
Könntest du mir bitte sagen an was es jetzt hängt?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Johann J. schrieb:
> Findest Du in der AVR-GCC-Toolchain 9.1 irgendeine Datei mit Namen
> "*4808*.*" ?

Wie oben erklärt erhält man den Support durch den Device-Pack.

> Mittlerweile habe ich das Atmel Studio 7.0 in einer Windows 10 VM frisch
> installiert - ein leeres ATMega4808-Projekt lässt sich problemlos
> kompilieren.

Weil der Support von Microchip händisch hinzugefügt wurde.  Oder hast du 
die Tools selbst generiert und ohne extra Device-Pack?

Es geht um die Generierung der Canadian-Cross Tools für GCC v9.1.

> Wenn Du eine andere Toolchain nutzen willst, dann sollte die den
> verwendeten Prozessor auch unterstützen (können) - sonst wird das
> nichts, wie Du siehst.

Der Prozessor Core ist ein avrxmega3, und den Support dafür enthält die 
avr-libc 2.0 noch nicht.  Daher wird SVN trunk verwendet und zur 
Generierung fehlen momentan noch die Autotools.

Johann J. schrieb:
> In der AVR-GCC-9.1-Toolchain von z.B.
> http://blog.zakkemble.net/avr-gcc-builds/ gibt es keine
> "*4808*.*"-Dateien.

Hatten wir alles schon.

Einfach mal den Thread lesen, bevor du jetzt bei Null anfängst.

#######################

Veit D. schrieb:
> Allerdings kann er die avr-libc nicht bauen.
> Irgendwie kann er entweder keine configure erstellen oder er findet
> keine weil es keine gibt.

Als Entwickler braucht man üblicherweise mehr Tools als der Anwender, 
der "nur" aus einer Release generiert :-)

Also autotools (autoconf, autoheader, automake, ...) installieren.

> ./bootstrap: 25: ./bootstrap: aclocal: not found
> + autoheader
> ./bootstrap: 26: ./bootstrap: autoheader: not found
> + autoconf
> ./bootstrap: 27: ./bootstrap: autoconf: not found
> + automake --foreign --add-missing --copy
> ./bootstrap: 28: ./bootstrap: automake: not found

Die Meldungen sagen ja was fehlt.
configure wird von autoconf aus configure.ac erstellt.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

vielleicht waren das zu viele Mitteilungen auf einmal. Ich bin auch kein 
Linuxkenner nur weil ich einen Linuxrechner habe. Ich kann die 
Fehlermeldungen nicht deuten. Ich kann nicht wissen das es sich um 
Programme handelt die ich einfach nachinstallieren kann/muss.

Danke für den Hinweis. Werde es nachinstallieren. Mal sehen was dann ist 
...

Beitrag #5920252 wurde vom Autor gelöscht.
von Veit D. (devil-elec)


Lesenswert?

Hallo,

würde sagen wollen ich habs geschafft. Was für eine Wahnsinnsaktion.
Ordner arvWindows32 hat 1550 Dateien und ist 228MB groß.
Für heute ist Schluss. Morgen teste ich das Ding in AS.
Danke erstmal für alles.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Johann L. schrieb:
> Laut http://gcc.gnu.org/PR91189 erzeugt avr-gxx v9 merklich größeren
> Code als v8.  Wenn's nicht den neuesten C++ Schnickes braucht, kann die
> v8.3 durchaus angesagt sein.

kannn ich bestätigen! ich verwende daher auch nur v8.3 für ältere und 
neuere avr's.


mt

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich wollte den 9.1 weil der komplette C++17 Unterstützung hat. Weil ich 
ein Buch habe für/mit C++17. Macht sich denn die Codegröße immer 
bemerkbar oder nur wenn man bestimmte Sprachmittel nutzt?

Übrigens kompiliert die selbstgebaute Toolchain in AS wenn ich vorher 
noch die fehlenden Dateien reinkopiere. :-) :-)  Ich mache das heute 
nochmal um meine Notizen zuprüfen.

Kann ich die Korrekturen von hier 1:1 übernehmen?
Beitrag "Re: cannot read spec file 'device-specs/specs-atmega4808'"

von A. B. (Gast)


Lesenswert?

War ein interessantes Hin und Her in diesem Thread.
Linux als Werkzeug aber nicht im Alltag. Geht mir manchmal auch so.
Der Linux-Profi kann sich die Nöte des Fragestellers nur bedingt 
vorstellen.

@Veit D.
Könntest du deinen schlussendlich zum Ziel führenden Lösungsweg bitte 
hier einstellen. Aktuelle (Win-)Toolchain erstellen und neue 
Mikrocontroller darin integrieren sind immer wiederkehrende Aufgaben.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Veit D. schrieb:
> Macht sich denn die Codegröße immer
> bemerkbar oder nur wenn man bestimmte Sprachmittel nutzt?

die macht sich immer und auch bei nur c source bemerkbar aber nicht mit 
+20% sondern mit "einigen bytes" mehr.


mt

von Veit D. (devil-elec)


Lesenswert?

Hallo,

haste richtig erkannt. Ein paar grundlegende Linuxkenntnisse habe ich 
ja. Aber die Nummer hier hatte mich fast zum Abbruch bewegt - 
zwischendurch. Meine Gedanken drehten sich nur noch um Pfade, Optionen, 
fehlende Software, Tippfehler, Probleme in Antergos mit der mingw 
Installation, Wechsel auf Ubuntu, wieder Pfade usw. Ich wusste 
zwischendurch nicht mehr wo mir der Kopf steht. Das kann sich jemand der 
voll im Saft steht sicherlich nicht vorstellen. Zudem nur die 
schriftliche Kommunikation da ist. Man erlebt etwas. :-) Ende gut alles 
gut.

Aber genug davon. Ohne Hilfe von Johann wäre das überhaupt nichts 
gewurden. Nochmal großes Danke das du mitgezogen hast. Zu den 
Bauoptionen werden später noch Fragen kommen. Also bitte nicht 
wegrennen.  :-)

Und ja, ich teste meine Notizen nochmal, wiederhole alles, fasse meine 
Scripte zusammen, dann wollte ich meine Anleitung sowieso reinstellen.

Codegröße - aha.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

überarbeitet, getestet und für gut befunden.

Das Einzigste was ich nicht schaffe sind die 3 Windows Scripte zu einem 
zusammenzuführen. Einzeln funktioniert es.

Viel Spass beim bauen.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

was ich noch testen konnte ist, wenn man alle drei Win32 Scripte aus 
einem heraus aufruft.
1
#!/bin/bash
2
3
set -x
4
5
sh buildWin32binutils.sh
6
7
sh buildWin32gcc.sh
8
9
sh buildWin32libc.sh

: Bearbeitet durch User
von Torsten S. (tse)


Lesenswert?

rar-Archive sind extrem unbeliebt (nicht nur) bei Linux-Freaks.

von Veit D. (devil-elec)


Lesenswert?

> rar-Archive sind extrem unbeliebt (nicht nur) bei Linux-Freaks.

Warum das denn? Ich nehme nur noch Rar. Wobei Rar auch in .zip packen 
kann. WinRar ist multikulti. Auf Linux ist .rar Standard. Ist extrem 
einfach zu handhaben.
Wenn ich WinZip nehmen würde, warum überhaupt?, kann denn dann 
sichergestellt werden das weltweit jeder das akutelle Packformat 
entpacken kann? Ich glaube es fast nicht.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

du hattest irgendwann etwas geschrieben das man mit dem gcc bauen soll 
für den man seine avr Toolchain bauen möchte. Meinst du damit man sollte 
sich die aktuelle gcc Version für das OS selbst installieren? Mit 
"build-essential" installiert sich Ubuntu gcc 7.4.0 auf die Platte.

Ich hätte noch gern gewusst was die Optionen von Zak für eine Bedeutung 
haben und ob diese für gcc 8.x und 9.x noch relevant sind. Sein 
einsehbares Script ist noch vom avr-gcc 7.3 Paket.
1
OPTS_GCC="
2
--disable-libssp
3
--disable-libada
4
--enable-static
5
--enable-mingw-wildcard

und ob diese "Addons" auch noch von Bedeutung sind für den 8.x und 9.1
1
DEFSFIX="
2
#if (defined _WIN32 || defined __CYGWIN__)
3
#define INT8_MIN (-128)
4
#define INT16_MIN (-32768)
5
#define INT8_MAX 127
6
#define INT16_MAX 32767
7
#define UINT8_MAX 0xff
8
#define UINT16_MAX 0xffff
9
"

und was hat die Option
[/code]
--build=`../config.guess`
[code]
für eine nähere Bedeutung?
Baut er dann automatisch wie für host angegeben?

Danke.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Wenns hilft, meinetwegen, dann leider ohne zusätzliche 
Wiederherstellungsdaten.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Nochmal großes Danke das du mitgezogen hast.

Keine Ursache. Ich find's gut wenn jemand am Ball bleibt und nicht bei 
dem kleinsten Problemchen "gibt's doch alles schon bei XYZ" das Handtuch 
wirft.

Veit D. schrieb:
> ich wollte den 9.1 weil der komplette C++17 Unterstützung hat.

Was fehlt denn bei v8? Gemäß

https://www.gnu.org/software/gcc/projects/cxx-status.html#cxx17

wurde zum letzten Mal durch v8 was zu C++17 hinzugefügt.  Alle 
Änderungen von v9 sind für C++20.


Veit D. schrieb:
> du hattest irgendwann etwas geschrieben das man mit dem gcc bauen soll
> für den man seine avr Toolchain bauen möchte. Meinst du damit man sollte
> sich die aktuelle gcc Version für das OS selbst installieren?

Nein.  Es sind folgende Toolchains im Spiel, wobei links die 
Build-Plattform steht und rechts die Target-Plattform, wobei (*) zu 
generieren sind:

A) linux->linux

B) linux->mingw32

C) linux->avr (*)

D) mingw->avr (*)

Für die Linux-Toolchain wird A verwendet um C zu generieren, und C wird 
dann verwendet, um avr Target-Libs zu erstellen.

Für die Mingw-Toolchain wird B verwendet um D zu generieren, und C wird 
dabei verwendet, um avr Target-Libc zu erzeugen (weil D nicht unter 
Linux ausführbar ist).  Daher muss C (und natürlich B) im Pfad sein wenn 
D erzeugt wird.

Der avr-Code, den D schließlich erstellt, setzt sich also aus Code von D 
zusammen (generiert) sowie aus vorcompiliertem Code von C.  D kombiniert 
also Code von C und D.

Wenn nun C und D nicht zusammenpassen, weil sich ein ABI geändert hat, 
dann kann es Probleme geben.  Natürlich versucht man, solche 
ABI-Änderungen zu vermeiden.  Aber wenn D z.B. neue Multilib-Varianten 
mitbringt, die C noch nicht kannte, dann fehlen diese Multilib-Varianten 
weil die Libs mit C erstellt wurden, und D verwendet dann den 
Multilib-Default (hier avr2) weil es die Lib-Variante nicht findet.

Entsprechende Änderungen gab es z.B. in v4.7, v5, und v8.

Am einfachsten ist es aber, wenn C und D die gleiche Version haben.

Die Versionen von A und B haben z.B. Einfluss auf die Host-Effizienz des 
generierten Compilers, nicht aber auf den generierten AVR-Code.  Denn 
die Ausgabe (AVR-Code) eines Programms (Compiler) muss unanhängig davon 
sein, wie das Programm (Compiler) generiert wurde.

> Ich hätte noch gern gewusst was die Optionen von Zak für eine Bedeutung
> haben und ob diese für gcc 8.x und 9.x noch relevant sind.

> --disable-libssp

Schon lange überflüssig, da für avr deaktiviert:

http://gcc.gnu.org/viewcvs/gcc/trunk/configure.ac?revision=272332&view=markup#l634

> --disable-libada

Sollst überflüssig sein, da GCC nur für C, C++ configured wird und nicht 
für Ada, daher braucht's auch keine Target Support Libs für Ada.

> --enable-static

Shared Target Bibliotheken werden für avr nicht unterstützt, sollte 
daher redundant / überflüssig sein.

> --enable-mingw-wildcard

Sinnvoll für mingw Builds, damit in "avr-gcc *.c" das "*" als Wildcard 
interpretiert wird und nicht als Teil eines Dateinamens.

> DEFSFIX=

Hab ich noch nie gebraucht oder gesehen, keine Ahnung welches "Problem" 
das beheben soll.

> und was hat die Option --build=`../config.guess` für eine
> nähere Bedeutung?

Kann man machen, ich bevorzuge --host, --build und --target explizit 
anzugeben.  Das bissl an configure-Zeit, was das spart, ist absolut 
unerheblich.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

Danke für die gute Erklärung.  :-)

Dann bin ich jetzt froh kein test PPA hinzufügen zu müssen damit Ubuntu 
selbst den aktuellen gcc hat. Wenn es nicht benötigt wird lasse ich 
davon die Finger.

C++ Version <> gcc Version.
Ich dachte immer das erst gcc 9 C++17 komplett indus hat.
Das hier hatte ich einmal gelesen.
https://www.heise.de/developer/meldung/GNU-Compiler-Collection-9-1-Support-fuer-D-C-17-vollstaendig-implementiert-4413698.html
Deswegen war ich der Meinung erst gcc 9 hat C++17 komplett und erste 
Teile von C++2a.

C++2a kann laut der Meldung noch nicht fertig sein. Ich gehe allerdings 
davon aus das 2a == 20 ist.
https://www.heise.de/developer/meldung/Programmiersprache-C-20-ist-Feature-Complete-4476070.html

Laut deinem Link allerdings sieht es aus das C++17 in gcc 8 komplett ist 
und 2a mit gcc 9 begonnen wurde inkl. wenige 2a Features noch in gcc 8 
Einzug hielten. So deute ich die Tabelle.

Wenn dem so ist und gcc 8 eh kleineren Code erzeugt, dann nehme ich eben 
gcc 8. Ist mir von der Sache her erstmal egal.

Eine Frage bleibt noch wegen der mingw 32Bit vs. 64Bit Version.
Hat das nur Einfluss auf die C/C++ µC Programm Kompilierung selbst 
bezüglich deren Geschwindigkeit oder was noch? Ich meine der µC selbst 
ist ja nur "8Bit". Da sehe ich mit der 64Bit Version keinen Vorteil - 
aus meiner Sicht. Vielleicht ist mein Blickwinkel falsch. Außer das es 
besser zum 64Bit Windows passt.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Ich dachte immer das erst gcc 9 C++17 komplett indus hat.

Das einzige, was sich wohl geändert hat, ist, dass die C++17 
Implementation nicht mehr als "experimentell" eingestuft ist.  Was immer 
das bedeutet.  Vielleicht dass es mit v8 vollständig war und es seit der 
v8 Release (Frühjahr 2018) eben von vielen[tm] Anwendern eingesetzt 
wurde und nicht mehr nur vornehmlich von GCC-Entwicklern und -Testern. 
Praxiserprobtheit ist ja auch ein Qualitätsmerkmal.

Veit D. schrieb:
> Eine Frage bleibt noch wegen der mingw 32Bit vs. 64Bit Version.
> Hat das nur Einfluss auf die C/C++ µC Programm Kompilierung selbst
> bezüglich deren Geschwindigkeit oder was noch?

Der Code läuft nicht aus 32-Bit Systemen, der 32-Bit Code aber auf 
64-Bit :-)

> Ich meine der µC selbst ist ja nur "8Bit". Da sehe ich mit der 64Bit
> Version keinen Vorteil - aus meiner Sicht.

Siehe:

Johann L. schrieb:
> Die Versionen von A und B haben z.B. Einfluss auf die Host-Effizienz des
> generierten Compilers, nicht aber auf den generierten AVR-Code.

Veit D. schrieb:
> damit Ubuntu selbst den aktuellen gcc hat.

Das ist nun wirklich einfach :-)  Die Quellen hast du ja schon, also 
einfach ein Build-Verzeichnis machen und dann
1
cd $GCC_BUILD
2
$GCC_SOURCE/configure --prefix=$HOME/gcc-native --disable-bootstrap
3
make
4
make install

und dann $HOME/gcc-native/bin zu PATH hinzu nehmen.  Mehr 
configure-Optionen brauch's nicht, evtl. noch --enable-languages=c,c++. 
Und Binutils oder Libc brauchen auch nicht generiert zu werden, die 
gibt's ja schon im System.  Und wenn dir der neue Compiler nicht 
gefällt, dann nimmst ihn einfach aus PATH raus und "rm -rf 
$HOME/gcc-native".

--disable-bootstrap kann auch weg, aber dann gib't ein 3-Stage Build, 
das dauert natütlich ne Zeit.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das liest sich hervorragand.  :-)
Danke.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

irgendwie möchte das nicht funktionieren.
Die fehlenden GMP, MPFR und MPC konnte ich ihm noch geben
1
cd $SOURCE
2
./contrib/download_prerequisites

Ich komme jedoch nicht mit warum er ein "Permission denied" auf meine 
eigens erstellten Verzeichnisse meldet. Die Rechte sind Tausend mal 
geprüft, kein root, sind meine "ubuntixer" Rechte.
Schaue ich ins Logfile habe ich das Gefühl das er außerdem noch auf die 
Ubuntu Source Quelle zugreifen möchte statt auf mein angegebenes 
Verzeichnis.

BUILD ist nur zum bauen da.
SOURCE ist die Entpackte gcc von hier 
ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-9.1.0/
DESTI wo das fertige Paket hin soll
1
+ BUILD= /home/ubuntixer/toolchain/buildLinuxTemp/
2
buildLinuxgcc.sh: 5: buildLinuxgcc.sh: /home/ubuntixer/toolchain/buildLinuxTemp/: Permission denied
3
+ SOURCE=/home/ubuntixer/Downloads/gcc-9.1.0/
4
+ DESTI= /home/ubuntixer/local/avr-gcc-9.1.0-linux/
5
buildLinuxgcc.sh: 7: buildLinuxgcc.sh: /home/ubuntixer/local/avr-gcc-9.1.0-linux/: Permission denied
6
+ cd
7
+ /home/ubuntixer/Downloads/gcc-9.1.0//configure --prefix= --enable-languages=c,c++ --disable-bootstrap
8
checking build system type... x86_64-pc-linux-gnu
9
checking host system type... x86_64-pc-linux-gnu
10
checking target system type... x86_64-pc-linux-gnu
11
checking for a BSD-compatible install... /usr/bin/install -c
12
checking whether ln works... yes
13
checking whether ln -s works... yes
14
checking for a sed that does not truncate output... /bin/sed
15
checking for gawk... no
16
checking for mawk... mawk
17
checking for libatomic support... yes
18
checking for libitm support... yes
19
checking for libsanitizer support... yes
20
checking for libvtv support... yes
21
checking for libhsail-rt support... yes
22
checking for libphobos support... yes
23
checking for gcc... gcc
24
checking whether the C compiler works... yes
25
checking for C compiler default output file name... a.out
26
checking for suffix of executables... 
27
checking whether we are cross compiling... no
28
checking for suffix of object files... o
29
checking whether we are using the GNU C compiler... yes
30
checking whether gcc accepts -g... yes
31
checking for gcc option to accept ISO C89... none needed
32
checking for g++... g++
33
checking whether we are using the GNU C++ compiler... yes
34
checking whether g++ accepts -g... yes
35
checking whether g++ accepts -static-libstdc++ -static-libgcc... yes
36
checking for gnatbind... no
37
checking for gnatmake... no
38
checking whether compiler driver understands Ada... no
39
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
40
checking for objdir... .libs
41
configure: WARNING: using in-tree isl, disabling version check
42
*** This configuration is not supported in the following subdirectories:
43
     gnattools gotools target-libada target-libhsail-rt target-libphobos target-zlib target-libbacktrace target-libgfortran target-libgo target-libffi target-libobjc target-liboffloadmic
44
    (Any other directories should still work fine.)
45
checking for default BUILD_CONFIG... 
46
checking for --enable-vtable-verify... no
47
/usr/bin/ld: cannot find Scrt1.o: No such file or directory
48
/usr/bin/ld: cannot find crti.o: No such file or directory
49
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a when searching for -lgcc
50
/usr/bin/ld: cannot find -lgcc
51
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc_s.so.1 when searching for libgcc_s.so.1
52
/usr/bin/ld: cannot find libgcc_s.so.1
53
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a when searching for -lgcc
54
/usr/bin/ld: cannot find -lgcc
55
collect2: error: ld returned 1 exit status
56
configure: error: I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.
57
+ make
58
make: *** Es wurden keine Ziele angegeben und keine „make“-Steuerdatei gefunden.  Schluss.
59
+ make install
60
make: *** Keine Regel, um „install“ zu erstellen.  Schluss.

mein Script
1
#!/bin/bash
2
3
set -x
4
5
BUILD= $HOME/toolchain/buildLinuxTemp/
6
SOURCE=$HOME/Downloads/gcc-9.1.0/
7
DESTI= $HOME/local/avr-gcc-9.1.0-linux/
8
9
# ggf. fehlende GMP, MPFR und MPC runterladen
10
# cd $SOURCE
11
# ./contrib/download_prerequisites
12
13
cd $BUILD
14
$SOURCE/configure --prefix=$DESTI --enable-languages=c,c++ --disable-bootstrap
15
make
16
make install

Logfile hängt dran. Bin ratlos.
Ideen?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> + /home/ubuntixer/Downloads/gcc-9.1.0//configure --prefix=
> --enable-languages=c,c++ --disable-bootstrap

Das --prefix ist kaputt.

> + DESTI= /home/ubuntixer/local/avr-gcc-9.1.0-linux/

Leerzeichen nach = ?

Aus gleichem Grund wurde im falschen Verzeichnis configured:

> + cd

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

config.log schrieb:

> I suspect your system does not have 32-bit development libraries
> (libc and headers). If you have them, rerun configure with
> --enable-multilib. If you do not have them, and want to build a
> 64-bit-only compiler, rerun configure with --disable-multilib.

Falls der Compiler nicht auf 32-Bit Hosts laufen können muss, kommt noch 
--disable-multilib hinzu.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

och menno, das Leerzeichen hinterm "Ist Gleich" in den Pfaddefinitionen 
war es. Hatte das der Optik wegen eingerückt. Hätte nicht gedacht das 
das ausgewertet wird. Kompiliert aktuell...
Danke.  :-)

von Veit D. (devil-elec)


Lesenswert?

Hallo,

wenn ich den Pfad hinzufüge und mit echo $PATH prüfe stimmt alles.
Mache ich einen Test mit
> gcc -version
erhalte ich immer noch Angaben von Ubuntu 7.4er Version
1
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
2
Copyright (C) 2017 Free Software Foundation, Inc.
3
This is free software; see the source for copying conditions.  There is NO
4
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Was läuft jetzt wieder schief?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Manche Shell cached Pfade zu Programmen; was PATH und which anzeigen 
stimmt dann nicht mehr undedingt mit dem was ausgeführt wird.

Versuch mal ne ganz neue Shell oder "hash -r" um die Hash-Tabellen zu 
resetten.

Was sagt --version wenn mit absolutem Pfad aufgerufen?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

muss erstmal neu bauen, weil gelöscht.  :-)
Es wird dann sowieso spannend, weil der PATH Eintrag laut meines Wissens 
nur temporär erfolgt. Shell schließen und öffnen und weg ist er. Man 
müßte es bei Erfolg in die /etc/environment eintragen - denke ich.

Edit:

ging schneller wie gedacht.

Also mit absoluter Pfadangabe funktioniert
> gcc --version.
Ohne Pfadangabe geht leider nichts.
hash -r hilft auch nicht.
In einem neuen Terminal erscheint ohne Pfadangabe auch wieder nur die 
installierte gcc 7.4 Weil dort der Pfadeintrag schon vergessen ist. Sagt 
mir echo $PATH.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

In /etc braucht man da nix ändern, es sei denn es soll systemweit sein.

Ein Weg ist, PATH im .bashrc zu erweitern oder welches rc deine Shell 
eben nutzt.

Was auch geht, ist $HOME/bin zu PATH hinzunehmen (z.B. in .bashrc) und 
dann Soft-Links zu setzen:
1
cd $HOME/bin
2
ln -s $PREFIX/.../bin/avr-gcc avr-gcc
3
ln -s $PREFIX/.../bin/avr-g++ avr-g++
Und dito für gcc / g++. Oder auch Links auf bestimmte Versionen:
1
ln -s $PREFIX/.../bin/avr-gcc-9.1.0 avr-gcc-9.1.0
so dass man eine bestimmte Compilerversion ganz einfach ansprechen kann.

Wenn man die Tools nicht mehr braucht, dann unlink $HOME/bin/avr-gcc 
etc.  Wenn man einen Link umhängt, also unlink + ln -s neu setzt, dann 
braucht man u.U. noch das hash -r.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich verstehe zwar ungefähr was du vorschlägst, aber das umzusetzen ist 
wohl nicht so leicht.

Wenn ich die gcc Version inkl. Pfadangabe abfrage zeigt er mir die 9.1 
wie gewollt.
Springe ich in den Pfad und rufe nur die gcc Version ab zeigt er mir 
wieder die im System installierte 7.4 an.

Ich möchte auch nicht permanent die Zusatzangabe zur 9.1 machen. Ist auf 
Dauer umständlich.
Füge ich den Pfad der 9.1 zum System fest zu, bleibt ja immer noch die 
7.4 vorhanden. Ich kenne den Suchmechanismus nicht. Theoretisch müsste 
er dann beide finden oder hört bei der Erstbesten auf zu suchen. Welche 
das ist weiß ich nicht. Meine Gedanken kreisen noch.

Normalerweise benötigt man einen Umschalter. Den gibts jedoch nicht.
Die Prefixänderung mit PATH ist wie gesagt nur temporär. Sobald die 
Shell geschlossen ist, ist das vergessen.

Wenn ich das in /etc/environment festnagel weiß ich leider immer noch 
nicht welchen gcc er dann zuerst findet.

Andere Frage.
Wenn ich die 7.4 deinstalliere, dann müßte ich doch mit sudo und make 
install die 9.1 stattdessen Systemweit installieren? Also die 9.1er 
nochmal bauen wie bisher aber mit sudo Rechten. Würde das funktionieren?

Übrigens, kann man noch die LTO Option aktivieren oder ist nur für avr 
target sinnvoll?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

was man in seiner selbstgebauten Toolchain auch noch hinzufügen muss 
sind die iomxxxx Dateien. avr/include/avr  In meinem Fall die iom4808.h, 
iom4809.h und selbst die iom328pb.h fehlte. Dann muss man diese noch in 
die io.h eintragen.
Fiel mir jetzt auf wo Registernamen für verschiedene µC definieren 
wollte.

von Veit D. (devil-elec)


Lesenswert?

Hallo Johann,

in den Ubuntu gcc müssen wir erstmal keine Energie stecken.

Es gibt etwas Wichtigeres bezüglich avr-gcc.

Ich bin gerade dabei die uart Lib von Peter Fleury anzupassen.
Ich ändere nichts weiter wie die Register- und Bitnamen und die der ISR.
Die Namen und Schreibweisen lese ich aus der iom4808.h raus.
Atmel Studio macht alles lila, bedeutet alles wie getippt bekannt und 
okay.
Ändere ich den letzten falschen Registernamen und kompiliere, erhalte 
ich 6x

pseudo instruction `__gcc_isr' not supported  usartRingbuffer 
C:\Users\devil\AppData\Local\Temp\cc8sib3J.s

Die angebene Datei gibts aber nicht im Verzeichnis.

Was tun?

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> pseudo instruction `__gcc_isr' not supported  usartRingbuffer
> C:\Users\devil\AppData\Local\Temp\cc8sib3J.s

Siehe

Beitrag "Re: cannot read spec file 'device-specs/specs-atmega4808'"

> Die angebene Datei gibts aber nicht im Verzeichnis.

Temporäre werden gelöscht, es sei dann man sage gcc -save-temps ...

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Mach mal -v dazu und such nach "Reading specs from", dann siehst du 
welches specs genommen wird.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

er greift auf die in der eingestellen Toolchain zu. Das ist aber eine 
kopierte specs Datei vom Atmel Devicepack. Wurde beim Toolchainbau nicht 
mit erzeugt.

Habe die Zeile in der spec ergänzt
1
*asm_gccisr:
2
  %{!mno-gas-isr-prologues: -mgcc-isr}

pseudo isr fehler ist weg
allerdings kommt ein neuer Fehler, betrifft auch die specs
1
cannot execute '*link_pmem_wrap:': CreateProcess: No such file or directory  usartRingbuffer  avr-g++.exe  0

Der Eintrag in der specs ist leer
1
*link_pmem_wrap:

Reagiert die specs auch auf die Anzahl der Leerzeilen?
Nehme ich nach
1
*link_text_start:
eine der zwei Leerzeilen raus erhalte ich
1
unknown core architecture 'atmega4808' specified with '-mmcu='  usartRingbuffer  cc1plus.exe  0


Das mit der old_link Korrektur habe ich noch nicht verstanden was ich wo 
ändern kann.
Und was das mit Archlinux (link_arch) zu tun hat?
Muss ich die letzten Zeilen mit rename und *link löschen und oben bei 
*link_arch mit deiner Korrektur ersetzen?

von Johann L. (gjlayde) Benutzerseite


Angehängte Dateien:

Lesenswert?

Veit D. schrieb:
> Reagiert die specs auch auf die Anzahl der Leerzeilen?

Ja.

von Johann L. (gjlayde) Benutzerseite


Angehängte Dateien:

Lesenswert?

specs

von Veit D. (devil-elec)


Lesenswert?

Hallo,

oh, bin positiv überrascht. Vielen vielen Dank für dein Korrekturpaket.
Da ist die Datei mit Reaktion auf Leerzeilen eine heikle Sache.
Habe natürlich die Dateien auch verglichen. Hast mehr Änderungen 
vorgenommen wie gedacht. Danke. Mir fällt noch ein Unterschied in den 
letzten Zeilen zwischen der 4808 und 4809 auf. Muss das so sein?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Mir fällt noch ein Unterschied in den letzten Zeilen zwischen
> der 4808 und 4809 auf. Muss das so sein?

Nein.

Wichtig ist, was am Ende in der *cpp Spec steht, weil das die Argumente 
sind, die der Treiber (avr-gcc) dem Präprozessor mitgibt.  Kann man 
alles in *cpp reinklatschen oder *cpp aus Sub-Specs per %(subspec) 
zusammenbasteln.  Nicht definierte Specs werden einfach ignoriert.

Zum Beispiel ist *asm, die Spec welche die Argumente für den Assembler 
transformiert, im avr Backend definiert als
1
#undef  ASM_SPEC
2
#define ASM_SPEC                                \
3
  "%(asm_arch) "                                \
4
  "%(asm_relax) "                               \
5
  "%(asm_rmw) "                                 \
6
  "%(asm_gccisr) "                              \
7
  "%(asm_errata_skip) "
weil das übersichtlicher im specs-File wird, das ja auch vom Anwender 
angefasst wird.  Außerdem kann man so neue spec-Files auch für ältere 
Compiler nehmen und bleibt abwärtskompatibel:  In älteren Versionen 
fehlt asm_gccisr, wird also ignoriert und der Assembler bekommt keine 
Option -mgcc-isr — die er möglicherweise nicht kennt — auch wenn 
asm_gccisr im Spec-File gesetzt wird.

Bei CPP_SPEC hatte ich diese Aufspaltung nicht gemacht, da wird *cpp 
direkt im specs-File gesetzt.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

scheinbar! verwechselt du etwas, da bin ich mir ziemlich sicher. Denn 
mit ausgewählten ATmega4809 kompiliert nichts mehr. Nehme ich die 
letzten Zeilen der 4808 spec Datei, kopiere diese in die 4809 spec Datei 
und ändere nur die 4808 zu 4809, kompiliert alles.
1
*cpp_avrlibc:
2
  -D__AVR_DEV_LIB_NAME__=m4809
3
4
*cpp_mcu:
5
  -D__AVR_ATmega4809__ -D__AVR_DEVICE_NAME__=atmega4809
6
7
*cpp_pm_base:
8
  -U__AVR_PM_BASE_ADDRESS__ -D__AVR_PM_BASE_ADDRESS__=0x4000
9
10
*cpp:
11
  %(cpp_mcu) %(cpp_pm_base) %(cpp_avrlibc)

Kannst du das bitte nochmal prüfen?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Was ist denn der Fehler?

Die oben angehängte Datei ist für ATmega809, nicht ATmega4809.  Weil 
µC.net die bereits hochgeladenen Dateien nicht angezeigt hatte, hab ich 
dann im nächsten Post ein zip hochgeladen.

von Johann L. (gjlayde) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hab grad mal was Einfaches für ATmega4809 generiert; gibt keine 
Probleme.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

die Vereinfachung kompiliert. Dann könnte man das auch für den 4808 
übernehmen?

Nochmal zum Problem von vorhin zurück. Die gezeigten Zeilen sind meine 
geänderten die kompiliert haben. In deinem ersten .zip scheint(e) die 
4809er specs fehlerhaft zu sein. Darauf wollte ich hinweisen. Jedenfalls 
kompilierte es vorhin nicht ohne eigenmächtige Änderung. Kann es aktuell 
aber mal wieder nicht reproduzieren. :-( Keine Ahnung warum. Mit 
Notepad++ und dem compare Plugin sehe ich Unterschiede wie vorhin auch. 
Egal, jetzt ist alles prima.  :-)

Ich gehe davon aus die Dateienpaare für
808/809,
1608/1609,
3208/3209,
4808/4809
bis auf die Nummer gleich sein sollten, was mir vorhin die Änderung 
ermöglichte.

Edit:
Jetzt haste mich abgehängt. Die zuletzt hochgeladene 4809 spec ist 
gleich der im .zip. Genau die vorhin nicht kompilieren wollte und 
aktuell kompiliert. Muss ich jetzt nicht verstehen.  :-)

Dann bleibt die Frage ob man die Vereinfachung für den 4808 übernehmen 
kann und ob die ATmega Paarungen bis auf die Nummer auch gleich sein 
sollten?

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich hätte noch eine Frage zum leidigen Thema avr-size. Alle gcc die ich 
abweichend von der AS Nativen verwende zeigen immer 0 an im Flash/RAM 
Verbrauch. Bisher habe ich mir damit beholfen die avr-size.exe der 
nativen Toolchain in die Neue zu kopieren. Bin mir aber nie sicher ob 
die angezeigten Werte exakt stimmen.

Jetzt bin ich über diesen Patch gestolpert.
https://gist.github.com/larsimmisch/4190960

Soweit ich das verstehe muss ich vorm Toolchain bauen die 
/binutils/size.c mit dem Patch ersetzen und fehlende µC ergänzen. Danach 
die Toolchain neu bauen. Wäre dann avr only.  :-)

Meine Frage wäre lohnt das oder zeigt die alte mitgeschleppte 
avr-size.exe weiterhin korrekte Werte an? Warum zeigen neuere 
avr-size.exe überhaupt 0 an? Auch mit alten µC.

Oder alles ganz anders?

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe ein Problem mit den crtatmega808.o (809) Dateien?

Ich habe mir heute eine neue Toolchain mit avr-gcc 9.2.0 gebaut. Deine 
spec Dateien und anderen fehlenden Dateien hinzukopiert und die io.h 
angepaßt etc. Dann habe ich mir einen kleinen Testcode für einen groben 
Test geschrieben. Dieser kompiliert mit

Atmega1608 , 1609
Atmega3208 , 3209
Atmega4808 , 4809

Attiny1614 , 1616 , 1617
Attiny3214 , 3216 , 3217

Nur mit dem Atmega808 , 809 meckert er mit
1
cannot find crtatmega809.o: No such file or directory  gcc-9.2.0-atmega-attiny-Test    
2
recipe for target 'gcc-9.2.0-atmega-attiny-Test.elf' failed  gcc-9.2.0-atmega-attiny-Test  C:\Users\devil\Documents\Atmel Studio\7.0\WorkSpace_ATmega4808\gcc-9.2.0-atmega-attiny-Test\gcc-9.2.0-atmega-attiny-Test\Debug\Makefile  106
Die crtatmega808.o Datei ist wie die anderen im Ordner
C:\avrToolchain\avr-gcc-9.2.0-mingw64-selfmade\avr\lib\avrxmega3\

Hast du eine Idee was schief läuft?



Was mich auch wundert aber bisher nicht gestört hat, vielleicht jetzt?, 
sind doppelte Dateien.

In der Zak Toolchain
C:\avrToolchain\avr-gcc-9.1.0_mingw32\avr\lib\avrxmega3\
Hier gibts von Haus nur die Dateien libc.a und libm.a. Es gibt keinen 
Unterordner.

In meinen selbst gebauten Toolchains gibt es immer im Ordner
C:\avrToolchain\avr-gcc-9.1.0-mingw64-selfmade\avr\lib\avrxmega3\
von Haus aus eine libc.a, libm.a libprintf_ftl.a, libprintf_min.a., 
libscanf_ftl.a, libscanf_min.a

Die gleichen Dateien gibt es nochmal im Unterordner \short-calls. Stört 
das?

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

Problem gelöst. :-)
Die Dateien der 808/809 müssen in den short-calls Unterordner.

C:\avrToolchain\avr-gcc-9.2.0-mingw64-selfmade\avr\lib\avrxmega3\short-c 
alls

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

habe ein Problem beim Toolchain bauen mit gcc 9.3.
Die gesamte Vorbereitung ist gleich geblieben.
Nur das ich auf gcc 9.3 und binutils 2.34 erneuert habe.
Jetzt scheitert schon der erste Buildprozess.
> configure: error: Wrong C compiler found; check the PATH!
Ich kann nicht erkennen wo der Pfad falsch ist.

Das Buildscript und die Konsolenausgabe im Anhang.

Wo liegt der Fehler?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

aktueller Stand. Zurück auf binutils 2.32. Gleiches Problem.
Zurück auf gcc 9.2.0, kompiliert komplett durch. Bedeutet aktuell nur 
das meine Scripte bis dahin noch funktionieren. Werde mich morgen wieder 
vorwärts tasten.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

> checking for avr-strip... no

Offenbar werden Binutils nicht gefunden.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das Thema hatte ich kurzerhand nach hier ausgelagert. Weil doch 
spezieller Natur.
Beitrag "Toochain bauen avr-gcc-x.x mit binutils-2.34 funktioniert nicht"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.