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?
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".
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.
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?
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
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.
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.
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.
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):
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.
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.
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.
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.
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?
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.
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?
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
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.
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?
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
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?
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
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.
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?
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
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.
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.
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
µ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
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\
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...
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.
?
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.
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. ?
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.
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.
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. :-)
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]
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. :-)
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.
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/
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
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?
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?
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?
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.
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
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.
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
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.
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.
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.
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.
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?
--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.
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?
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.
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.
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.
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.
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
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
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.
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.
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. :-)
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.
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.
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:
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.
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
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.
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.
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
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.
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.
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 ...
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 :-)
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
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.
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
...
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.
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
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'"
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.
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
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.
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.
> 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.
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.
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.
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.
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
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.
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
/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.
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
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.
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. :-)
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.
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?
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.
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.
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?
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.
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?
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?
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?
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.
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.
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.
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?
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?
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?
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
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?
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.
Thread beobachten
Seitenaufteilung abschalten