Hallo,
ich habe heute auf einem Linux System die aktuelle msp-gcc Version aus
sourcen erstellt - gemäß dieser Anleitung:
http://sourceforge.net/apps/mediawiki/mspg/index.php?title=Install:fromsource
Bei dem Versuch c Dateien damit zu kompilieren, kommt die Fehlermeldung:
as: unrecognized option '-mcpu=430'
Der aufgerufene assembler as kann also mit der Option -mcpu=430 nichts
anfangen.
Hätte der richtige assembler mit dem gcc mit installiert werden sollen?
Bei der älteren Version von mspgcc (aus rpm installiert) gab es das
Problem nicht.
Oder sollte eigentlich msp430-as statt as aufegrufen werden (Was mich
nur bedingt weiter bringen würde, da msp430-as auf meinem System auch
nicht vorhanden ist)?
Gruß, Jan
tux_persönlich schrieb:> Der link scheint defekt.
Ich hoffe jetzt gehts:
http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:fromsource
Ich benutze eclipse, der Compileraufruf wenn ich die mmcu angebe ist:
msp430-gcc -O0 -g3 -Wall -c -fmessage-length=0 -mmcu=msp430fg2452 -MMD
-MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
Und ohne mmcu, nur zum test:
msp430-gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d"
-MT"main.d" -o "main.o" "../main.c"
Gibt jedes mal den Fehler:
as: unrecognized option '-mcpu=430'
Selbst wenn ich mspgcc über die Kommanozeile mit minimale Optionen
aufrufe, gibt es den gleichen Fehler:
$msp430-gcc -o main main.c
as: unrecognized option '-mcpu=430'
>frag ihn doch was er gern hätte: msp-gcc --target-help
Ansich scheint mir -mmcu=msp430fg2452 schon richtig zu sein, steht ja im
Endefekt auch in dem verlinkte makefile.
Die Fehlermeldung bezieht sich auf as (also auf den aufgerufenen
Assembler und nicht gcc selbst) und auf -mcpu
Danke, Jan
> as: unrecognized option '-mcpu=430'
Sollte das nicht eigentlich "msp430-as" heissen? Wenn der GCC die
binutils vom Host (i386/x86_64) benutzt, würde das diesen Fehler
erklären. Pack mal ein "-v" zu den Compiler Optionen dazu, dann zeigt er
an was er für Kommandos ausführt - auch welchen Assembler.
Jim Meba schrieb:
Pack mal ein "-v" zu den Compiler Optionen dazu, dann zeigt er
> an was er für Kommandos ausführt - auch welchen Assembler.
Danke für den Tipp, folgendes ruft der msp430-gcc auf:
COLLECT_GCC_OPTIONS='-v' '-o' 'main' '-mcpu=430' '-mmpy=none'
'-mivcnt=16'
as -mcpu=430 -o /tmp/ccvcidfT.o /tmp/cccSpNQD.s
Allerdings kann ich msp430-as auch auf dem System nicht finden. Dann ist
wohl das installieren der binutils schief gelaufen, oder woher sollte
msp430-as kommen?
Gruß, Jan
Etliche Versuche später gibt es neue Erkenntnisse und auch Fragen, aber
leider kein Lösung:
-Scheinbar ist das installieren der msp430-binutils gemäß oben erwähnter
Anweisung schief gelaufen - und as gehört zu den binutils (sowohl make
als auch make install lieferten Fehler zurück)
-Ich konnte über yum die msp430-binutils installieren, allerdings nur in
Version 2.19. Damit ist msp430-as installiert, aber in Version 2.19
werden wieder manche msp Typen nicht unterstüzt (und das war der Anlass
für die ganze Aktion.)
Nun zu den Fragen, vielleicht hat ja jemand eine ähnliche Konfiguration:
-Sollte msp430-gcc-4.6.3 den msp430-as aufrufen, oder as -mcpu=430
-Und wo lässt sich das beeinflussen, da muß es doch irgendwelche config
files für den gcc geben, oder?
Gruß, Jan
Hi,
unabhängig der bisherigen Diskussion eine Anmerkung:
Falls du Ubuntu benutzt kannst du ganz bequem die Toolchain
via http://wiki.ubuntuusers.de/MSP430-Toolchain installieren.
Damit läuft alles in 5min, Idiotensicher! ;)
glgl hf
Cannabis_engineer schrieb:> Falls du Ubuntu benutzt kannst du ganz bequem die Toolchain> via http://wiki.ubuntuusers.de/MSP430-Toolchain installieren.
schade, ich verwende Fedora 16. Und dafür gibt es in den normalen
repositories nur msp430-gcc 3.x. Auch für das aktuelle Fedora 17 scheint
das ähnlich zu sein! Außerdem ist alle halbe Jahr auf die neuere OS
Version zu wechseln ja auch doof - bringt immer nur andere Probleme mit
sich.
Interessant wäre nochmal, wo definiert ist welchen assembler msp430-gcc
mit welchen Optionen aufruft. Dann kriege ich das eventuell auch zu Fuß
gelöst.
Ich habe eben mal zum Spass die neue binutils-2.23.1 compiliert.
Natürlich ohne Patch. Da ist alles wie es sein soll mit msp430-ar,
msp430-as usw.
Ohne jetzt den Patch der in deinem link angegeben ist zu analysieren
vermute ich darin das Problem.
also:
Hallo,
der
msp430-gcc ruft normalerweise dein msp430-as und auch alle anderen
Programme mit diesem Prefix auf, also auch msp430-ld.
Als Fallback werden dann eben die Tools ohne den Prefix "msp430-"
benutzt.
Also as, was bei bei einem x86 System leider nur den i386 usw.
unterstützt.
Ein "as -mcpu=430" bei einem x86 Host gibt es nicht.
Jan S. schrieb:> Interessant wäre nochmal, wo definiert ist welchen assembler msp430-gcc> mit welchen Optionen aufruft. Dann kriege ich das eventuell auch zu Fuß> gelöst.
msp430-gcc -dumpspecs
Interessant sind für dich:
*asm
*asm_debug
*asm_final
*asm_options
und vor allem:
*invoke_as
Beachte aber, daß gcc den as aufruft und diesen im richtigen Verzeichnis
erwartet, etwa in $install/$target/bin
Wenn er dort nicht ist, liegt das i.d.R an einer fehlkonfigurierten
Toolchain, oder daß beim Konfigurieren ein as bzw. eine Setup verwendet
wurde, wie es in der Installation nicht mehr vorgefunden wird.
Eine Möglichkeit, solchen Problemchen aus dem Weg zu gehen, ist GCC und
Binutils mit gleichem --prefix zu konfigurieren und beides zusammen zu
liefern.
Den Systempfad kannst du mit -B erweitern, aber es sollte auch ohne
gehen.
Wie gcc den as aufruft siehst du mit -v. Ergebnis hängt davon ab, wo
der "nächste" as gefunden wird.
Vielen Dank für die vielen Tipps.
Also msp430-as ist jetzt vorhanden, da es funktioniert hat ein
msp430-binutils Paket einer späteren fedora Version zu installieren.
msp430-as -v ergibt folgendes:
GNU assembler version 2.21.1 (msp430) using BFD version (GNU Binutils)
2.21.1 (mspgcc LTS 20120406 unpatched)
Dürfte also ok sein.
msp430-gcc -dumpspecs hat ergeben, daß unter der Direktive *invoke-as
eben "as" steht und nicht "msp430-as".
Habe den gesamten dump in eine Datei umgeleitet, as in msp430-as
geändert und gcc diese Datei mittels -specs= verwenden lassen. Und siehe
da, der Fehler hat sich verändert:
/usr/bin/msp430-ld: cannot find crt0ivtbl16.o: No such file or directory
/usr/bin/msp430-ld: cannot find -lgcc
/usr/bin/msp430-ld: cannot find -lc
/usr/bin/msp430-ld: cannot find -lgcc
/usr/bin/msp430-ld: cannot find -lcrt0
Damit werde ich mich dann wohl morgen weiter befassen müssen, es reicht
mir für heute.
Danke für die bisherigen Antworten, Jan
>Den>--prefix=/tmp>habe ich genommen, damit auf meiner Ramdisk/tmpfs gebaut wird.
.... und die Tools mit einem Shutdown rückstandsfrei entsorgt werden?
@ Johann L.
Ich wollte damit Jan S. nur sagen das die Anleitung funktioniert.
--prefix kann auch mit anderen Werten benutzt werden.
und wegen --disable-nls du kannst ja auch
1
LANG="en_US.UTF8"/tmp/msp430/bin/gcc-v
benutzen ;-)
@ Fotos und Scans
Ja war auch so gedacht !
Aktuell benutze ich keinen MSP430 sondern nur ARM und MIPS (Linux)
Und ich möchte nicht das ich Tools außerhalb meiner Distro (Gentoo)
installieren.
Unter Gentoo mit kann man mit
Hans Ulli Kroll schrieb:> Folgender Patch fehlt in der Downloadliste> http://sourceforge.net/projects/mspgcc/files/Patch...> wird aber im "Build" angewendet.>
Also wenn ich das richtig sehe, ist der patch in dem Archiv
mspgcc-20120406.tar.bz2 enthalten. den patch daraus habe ich zumindest
angewendet.
Ich habe msp430-gcc nochmal neu installiert, nachdem die binutils und
damit msp430-as ja nun vorhanden sind. Trotzdem wird noch as statt
masp430-as aufgerufen. Das läßt sich aber ja über die externe specfile
beheben.
Nun bleiben die Linkerprobleme, konkret:
1
Linking test.elf
2
/usr/bin/msp430-ld: cannot find -lc
3
collect2: ld gab 1 als Ende-Status zurück
4
make: *** [test.elf] Fehler 1
-lc kam in den specs vor, habe es spaßeshalber mal entfernt, der Fehler
bleibt aber.
Was soll -lc den überhaupt sein? Eine Option für msp430-ld?
Gruß, Jan
>Was soll -lc den überhaupt sein? Eine Option für msp430-ld?
Was hältst Du davon, die GCC/Biinutils-Manuals zu lesen?
-lc ist die Anweisung an den Linker, die Library
libc.a zu linken.
Generell: -l<libname> heisst
eine Library mit dem Namen lib<libname>.a zu linken (etwas
abgedreht, ich weiss, stammt halt aus der Unix-Historie).
Mit -L<lib-dir> kannst Du ein Directory festlegen, in dem Libs
gesucht werden.
Eine (oder mehrere solcher) sollten eigentlich beim
Build des Compilers entstehen....
Bei mir gibt´s u.a. eine
./msp430/lib/libc.a oder eine
./msp430/lib/mcpu-430x/libc.a
Hast Du das Readme beim mpsp430 GCC beachtet? Sollte
eigentlich alles ohne krude Hacks funktionieren.
Fotos und Scans schrieb:> Sollte eigentlich alles ohne krude Hacks funktionieren.
ACK. Insbesondere ist es nicht notwendig, die Specs zu hacken. Falls
doch, liegt ein grundlegendes Problem vor: Tools sind falsch
konfiguriert und / oder falsch installiert, etc.
Fotos und Scans schrieb:> Was hältst Du davon, die GCC/Biinutils-Manuals zu lesen?> -lc ist die Anweisung an den Linker, die Library> libc.a zu linken
Ich hab in das man von ld geschaut, aber hab blöderweise nach -lc statt
nach -l gesucht. Eigentlich dämlich, aber ich hab mich von den
mehrbuchstabigen gcc Option die nur mit einem - beginnen irritieren
lassen...
Johann L. schrieb:>> Sollte eigentlich alles ohne krude Hacks funktionieren.>> ACK. Insbesondere ist es nicht notwendig, die Specs zu hacken. Falls> doch, liegt ein grundlegendes Problem vor: Tools sind falsch> konfiguriert und / oder falsch installiert, etc.
Gut, dann sollte ich wohl nochmal von vorn anfangen. Mist, eigentlich
wollte ich doch nur mal schnell ...
Danke bis hier hin für die Geduld!
Bei configure macht GCC zentnerweise Ausgaben, die u.a. auch verraten,
welche binutils er nimmt. Steht darin fast ganz oben.
Schau also mal die configure-Ausgaben and bzw. das entsprechende
config.log.
Bei der installierten Tools kommt es auch darauf an, was in PATH
gefunden wird. Werden gcc und binutils zusammen erzeugt, wird jedoch
zuerst nach as gesucht, zB in ./$target/bin/as
@ Jan S.
von WO jast du den Compiler installiert ??
Du kannst diesen nicht aus dem Repo von Debian/Suse usw. nehmen ...
Du must den Compiler mit den dir selber gebauten binutils bauen.
Hier mal die wichtigen Ausgaben von "make binutils" (mit meinem
--prefix=/tmp
Der Vorteil von der richtigen Anwendung des --prefix du brauchst nicht
root zu sein um funktionierende toolchain zu haben
Beachte hier die Ausgabe von den gefundenen binutils, da ich ja meine
mit mit dem Prefix /tmp gebaut habe.
Normalerweise wird eine Toolchain mit dem entsprechenden "Tupel" gebaut.
Im msp30 Fall ist es wie du siehst msp430-unknown-none.
Der Standard Ausruf von ./configure, wenn diese aks root instaliert
werden sollen, ist :
Hans Ulli Kroll schrieb:> Hier mal die wichtigen Ausgaben von "make binutils"> [...]> Wie du siehst es darf kein Compiler erkannt werden
Huh? Wieso das?
Sollte doch nicht stören das, aber configure brabbelt eben viel...
Hans Ulli Kroll schrieb:> Der Standard Ausruf von ./configure, wenn diese> als root instaliert
Nicht, wenn man nicht root ist ;-)
Zudem wird ./configure in GCC nicht unterstützt, d.h. configure
innerhalb des Quellbaums. Falls man es doch gemacht hat, dann 1) Doku
lesen 2) Quellen entsorgen 3) Quellen neu ziehen 4) Anwenden, was in 1)
steht, also insbesondere kein configure im Quellverzeichnis.
Kaum macht man es richtig, schon geht es!
Asche über mein Haupt, es haben schlicht und einfach Abhängigkeiten
gefehlt.
Eine Hilfreiche Liste dazu in dieser Anleitung:
http://www.dconstructing.com/2012/02/22/compiling-for-msp430g2553-in-fedora
Dadurch wurden die binutils nicht und der gcc falsch installiert. Mit
den msp430-binutils als rpm hatte es ja auch nicht geklappt, ob dies an
einer inkompatibilität zwischen dem binutils Paket und dem aus sourcen
installiertem gcc lag, oder aber auch an nicht aufgelösten
Abhängigkeiten habe ich icht mehr nachgeforscht. Jetzt ist auf jeden
Fall alles manuell installiert (bis auf mspdebug) und funktioniert (gdb
habe ich noch nicht getestet).
Vielen Dank nochmal für Eure Hilfe, ich hab viel über gcc, die binutils
und cross compiling gelernt.
Übrigens steht in den specs von msp430-gcc interessanter weise immer
noch nur as statt msp430-as bei *invoke_as.
Jan
Noch ein Link zu LFS, Linux from Scratch
http://www.linuxfromscratch.org/lfs/
Dort wird das mit den bintuils und gcc nochmal erklärt. Sowie wie man es
schafft eine Toolchain vom Hostsystem zu "lösen". Dazu ist auch dieses
spec-File da. Die Suchpfade für die libs sind mit in dem Programmen
compiliert.
Thread beobachten
Seitenaufteilung abschalten