mikrocontroller.net

Forum: Compiler & IDEs Problem mit dem "Script for building AVR-GCC 4.2.2 on Linux"


Autor: Tux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche mit dem Bingo600 Script

http://www.avrfreaks.net/index.php?name=PNphpBB2&f...

unter Ubuntu 8.04 die AVR-GCC toolchain zu erstellen.


Leider erhalte ich folgenden Fehler
-----------------------------------

(./buildavr-no-insight.sh) building avrdude
make  all-recursive
make[1]: Betrete Verzeichnis '/usr/local/avr/build/avrdude-5.5'
make[2]: Betrete Verzeichnis '/usr/local/avr/build/avrdude-5.5'
gcc  -g -O2   -o avrdude  avrdude-main.o ./libavrdude.a   -lncurses 
-ltermcap
./libavrdude.a(libavrdude_a-config.o): In function `read_config':
/usr/local/avr/build/avrdude-5.5/../../source/avrdude-5.5/config.c:299: 
undefined reference to `yyin'
./libavrdude.a(libavrdude_a-config_gram.o): In function `yyparse':
/usr/local/avr/build/avrdude-5.5/config_gram.c:908: undefined reference 
to `yylex'
/usr/local/avr/build/avrdude-5.5/config_gram.c:2163: undefined reference 
to `yylex'
collect2: ld gab 1 als Ende-Status zurück
make[2]: *** [avrdude] Fehler 1
make[2]: Verlasse Verzeichnis '/usr/local/avr/build/avrdude-5.5'
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlasse Verzeichnis '/usr/local/avr/build/avrdude-5.5'
make: *** [all] Fehler 2
(./buildavr-no-insight.sh) avrdude build failed


Ich habe "flex" und "bison" installiert.

Ich komme an dieser Stelle nicht mehr weiter.

Danke für jede Hilfe

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein lex muss irgendwie kaputt sein.  Diese beiden Symbole sind
normalerweise im Parser definiert:
% nm ~/src/avrdude/libavrdude_a-lexer.o | fgrep -v ' U '
0000000000000870 t input
0000000000001740 r yy_accept
0000000000002200 r yy_base
0000000000000010 b yy_c_buf_p
0000000000000f80 r yy_chk
0000000000000400 T yy_create_buffer
0000000000000008 b yy_current_buffer
00000000000008a0 r yy_def
00000000000004e0 T yy_delete_buffer
0000000000000024 b yy_did_buffer_switch_on_eof
0000000000001e00 r yy_ec
00000000000001d0 t yy_fatal_error
00000000000001c0 t yy_flex_alloc
00000000000004d0 t yy_flex_free
0000000000000170 T yy_flush_buffer
0000000000000530 t yy_get_next_buffer
0000000000000000 t yy_get_previous_state
000000000000001c b yy_hold_char
0000000000000000 d yy_init
0000000000000390 T yy_init_buffer
0000000000000030 b yy_last_accepting_cpos
0000000000000028 b yy_last_accepting_state
00000000000000d0 T yy_load_buffer_state
00000000000007c0 r yy_meta
0000000000000020 b yy_n_chars
0000000000000000 r yy_nxt
0000000000000200 T yy_scan_buffer
00000000000002c0 T yy_scan_bytes
0000000000000370 T yy_scan_string
0000000000000018 b yy_start
0000000000000110 T yy_switch_to_buffer
0000000000000008 C yyin
                 ^^^^^^
0000000000000004 C yyleng
0000000000000960 T yylex
                 ^^^^^^^
0000000000000000 B yyout
0000000000000480 T yyrestart
0000000000000008 C yytext

Autor: Tux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nochmals die Packete 'flex' und 'bison' installiert
und das Script ./buildavr-no-insight.sh aufgerufen.
Meine Hoffnung war das hier etwas beschädigt ist.

Leider komme ich nicht über die Fehlermeldung wie oben hinaus.

Kann es evtl. daran liegen das bei Ubuntu 'lex' = 'flex' ist ?

Leider kenne ich mich (noch) nicht so gut in Linux aus damit ich
den Fehler selbst finden könnte.

Was bedeutet Dein vorheriger Beitrag mit dem Parser ?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tux wrote:

> Kann es evtl. daran liegen das bei Ubuntu 'lex' = 'flex' ist ?

Nein, das ist normal, außer vielleicht bei Solaris, da wird es noch
einen klassischen lex geben (und den flex parallel).

> Leider kenne ich mich (noch) nicht so gut in Linux aus damit ich
> den Fehler selbst finden könnte.

Ich habe dir doch das Kommando aufgeschrieben, mit dem ich die
Symboltabelle extrahiert habe.  Vergleich das mal mit dem Zustand
bei dir.

> Was bedeutet Dein vorheriger Beitrag mit dem Parser ?

Das hätte besser "Scanner" heißen sollen als "Parser".  Der Scanner
ist die untere Schicht in der Verarbeitung der Eingabe, eben auch
Lexer genannt.  Der Parser steckt in config_gram.y.

Autor: Tux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hinweise.
Ich habe das mit dem Kommando ausprobiert.

Bei mir befindet sich die Datei "libavrdude_a-lexer.o" unter

/usr/local/avr/build/avrdude-5.5

Bei Dir ./avr/src/avrdude/

Jedenfalls, wenn ich das Kommando in der Konsole eingebe

desktop:/usr/local/avr/build/avrdude-5.5$ nm libavrdude_a-lexer.o | 
fgrep -v ' U '
desktop:/usr/local/avr/build/avrdude-5.5$

kommt keine Ausgabe.

Du hattest oben geschrieben das die Symbole im Parser bzw. Scanner 
definiert sind. Darum habe ich mit "objdump" folgendes getestet (als 
Kommandozeilenparameter einmal mit -t bzw. -T weil ich im help dazu 
etwas mit "Symbol Tabelle" gelesen habe).

desktop:/usr/local/avr/build/avrdude-5.5$ objdump libavrdude_a-lexer.o 
-t | fgrep -v ' U '

libavrdude_a-lexer.o:     file format elf32-i386

SYMBOL TABLE:
00000000 l    df ABS  00000000 lexer.c
00000000 l    d  .text  00000000 .text
00000000 l    d  .data  00000000 .data
00000000 l    d  .bss  00000000 .bss
00000000 l    d  .debug_abbrev  00000000 .debug_abbrev
00000000 l    d  .debug_info  00000000 .debug_info
00000000 l    d  .debug_line  00000000 .debug_line
00000000 l    d  .note.GNU-stack  00000000 .note.GNU-stack
00000000 l    d  .comment  00000000 .comment


desktop:/usr/local/avr/build/avrdude-5.5$ objdump libavrdude_a-lexer.o 
-T | fgrep -v ' U '
objdump: libavrdude_a-lexer.o: not a dynamic object

libavrdude_a-lexer.o:     file format elf32-i386

DYNAMIC SYMBOL TABLE:
no symbols

desktop:/usr/local/avr/build/avrdude-5.5$

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht so aus, als hättest du da eine leere Objektdatei, d. h. dein
(f)lex hat einfach gar nichts erzeugt.

Kannst du mal alles neu bauen und dann die Datei lexer.c ansehen.
Diese Datei wird vom flex aus lexer.l generiert, sie ist bei mir
81 KiB groß.  Ich weiß gar nicht, legt Bingo600s Script irgendwo
ein Build-Log hin?  Dann kannst du ja dort nochmal das flex-Kommando
raussuchen, ob das irgendwelche Warnungen etc. erzeugt hat.  Bei
mir sieht der entsprechende Teil so aus (steht gleich ganz am Anfang
des avrdude-Logs):
make  all-recursive
bison -y -d -d config_gram.y
if test -f y.tab.h; then  to=`echo "config_gram_H" | sed  -e 'y/abcdefghijklmnopqrstuvwxyz/AB
CDEFGHIJKLMNOPQRSTUVWXYZ/'  -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`;  sed -e "/^#/!b" -e "s
/Y_TAB_H/$to/g" -e "s|y\.tab\.h|config_gram.h|"  y.tab.h >config_gram.ht;  rm -f y.tab.h;  if
 cmp -s config_gram.ht config_gram.h; then  rm -f config_gram.ht ; else  mv config_gram.ht co
nfig_gram.h;  fi;  fi
if test -f y.output; then  mv y.output config_gram.output;  fi
sed '/^#/ s|y\.tab\.c|config_gram.c|' y.tab.c >config_gram.ct && mv config_gram.ct config_gram.c
rm -f y.tab.c
if gcc -DHAVE_CONFIG_H -I. -I. -I.  -DCONFIG_DIR=\"/usr/local/etc\"  -Wall -g -O -I/usr/local/include -MT libavrdude_a-config_gram.o -MD -MP -MF ".deps/libavrdude_a-config_gram.Tpo" -c -o libavrdude_a-config_gram.o `test -f 'config_gram.c' || echo './'`config_gram.c;  then mv -f ".deps/libavrdude_a-config_gram.Tpo" ".deps/libavrdude_a-config_gram.Po"; else rm -f ".deps/libavrdude_a-config_gram.Tpo"; exit 1; fi
flex   lexer.l
sed '/^#/ s|lex.yy\.c|lexer.c|' lex.yy.c >lexer.c
rm -f lex.yy.c
if gcc -DHAVE_CONFIG_H -I. -I. -I.  -DCONFIG_DIR=\"/usr/local/etc\"  -Wall -g -O -I/usr/local/include -MT libavrdude_a-lexer.o -MD -MP -MF ".deps/libavrdude_a-lexer.Tpo" -c -o libavrdude_a-lexer.o `test -f 'lexer.c' || echo './'`lexer.c;  then mv -f ".deps/libavrdude_a-lexer.Tpo" ".deps/libavrdude_a-lexer.Po"; else rm -f ".deps/libavrdude_a-lexer.Tpo"; exit 1; fi
...

Autor: Tux (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nochmals alles neu gebaut

Aufruf für das erste Script:
desktop:~/make-avr-gcc$ ./buildinsight.sh

Dieser Built läuft bis zum Ende durch
-> installation of avr GNU tools complete

Die Datei "lexer.c" in "/usr/local/avr/build/avrdude-5.5"
ist 0 Byte (kein Inhalt)

Aufruf für das zweite Script:
desktop:~/make-avr-gcc$ ./buildavr-no-insight.sh

Danach gibt es die Fehlermeldung aus meinem ersten Beitrag oben.

In Bingo600 Script gibt es ein Logfile (wird nach /tmp gespeichert).

Ich habe das Logfile für das zweite Script als Anhang eingefügt.

.....
.....
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
.....
.....

Die Meldung von Dir in Deinem letzten Beitrag konnte ich bei
mir im Logfile nicht finden.

Die Datei libavrdude_a-lexer.o ist 853 Byte groß.

Es tut mir leid damit ich mich nicht so gut auskenne wie dieser
Built abläuft und wo ich noch suchen könnte.

Gibt es ne Möglichkeit, eine komplett kompilierte Toolchain zu erhalten
die ich dann z.B. nach /usr/local/avr kopiere und den PATH darauf setze?

Allerdings würde mich dennoch interessieren, warum das bei mir nicht 
geht.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe nochmals alles neu gebaut

Ich glaube nicht. Da waren noch die ganze kompilierten Dateien aus dem
letzten Build-Versuch vorhanden, sonst würde im Logfile mehr stehen.

Am besten löschst du erst einmal die ganzen Altlasten, indem du
im Verzeichnis /usr/local/avr/build/avrdude-5.5 einen
make clean

machst. Dabei wird u.a. auch das unglückselige lexer.c gelöscht.

Dann versuchst den Build noch einmal. Falls der Fehler wieder kommt,
postet du das neue buildavr.log, das jetzt deutlich länger sein sollte
als dein letztes. Daraus sollte man erkennen können, was beim Flexen
schief gelaufen ist.

Autor: Tux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für Eure Hilfe ! Das mit dem "make clean" war der 
entscheidende Hinweis.Nun hat es geklappt.

Ich habe vorgestern, als ich das erste mal das Skript gestartet habe, 
die Packete bison und flex nachinstalliert. Aber ich hatte nie mit einem 
"make clean" die alten Built Versuche beseitigt sondern immer nur das 
Skript neu gestartet.

Zumindest habe ich was dazugelernt, danke nochmals für die 
Unterstützung.

Autor: Tux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch eine Frage.
Kann ich das "WinAVR makefile" (Vorlage von Jörg Wunsch) auch so unter 
Linux
verwenden oder muss ich dort etwas noch abändern.

Die Demobeispiele (e.g. LargeDemo) kann ich bereits unter Linux
kompilieren.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tux wrote:

> Kann ich das "WinAVR makefile" (Vorlage von Jörg Wunsch) auch so unter
> Linux
> verwenden oder muss ich dort etwas noch abändern.

It depends.  Im Großen und Ganzen sollte es gehen.  Ich weiß nur nicht,
ob Bingo600 den schrägen Hack mit dem avr-size -C auch mit eingebaut
hat oder nicht.  Falls nicht, müsstest du den Aufruf von avr-size auf
-B abändern.

Falls du mit dem GDB debuggen willst, müsstest du statt -gdwarf-2
die Option -gstabs benutzen (sollte effektiv identisch zu einfach nur
-g sein), da der AVR-GDB DWARF-2 nicht ernsthaft versteht, dafür aber
mit stabs gut zurecht kommt.  Bei AVR Studio ist es genau anders
herum, daher ist die Voreinstellung im WinAVR-Makefile natürlich 
DWARF-2.

Autor: Tux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die makefile Vorlage aus dem WINAVR funktioniert bei mir.

Nun kann ich richtig unter Linux mit AVR loslegen :-)

Werde mir demnächst ein Buch zum Thema "Makefiles" kaufen um
auch mal zu verstehen, was die einzelnen Befehle bedeuten.

Jörg und Yalu, ich möchte mich bei Euch nochmals bedanken !

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
It depends.  Im Großen und Ganzen sollte es gehen.  Ich weiß nur nicht,
ob Bingo600 den schrägen Hack mit dem avr-size -C auch mit eingebaut
hat oder nicht.  Falls nicht, müsstest du den Aufruf von avr-size auf
-B abändern.

Er hat die avr-size "Hack" (binutils patch from WinAVR) eingebaut :-)

(Blushing....)

mfg
Bingo aka Bingo600

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I'll write this in english

The best "make clean" if the build fails is:

rm -fR /usr/local/avr

This must also be done manually (or a mv) if you build a new version of 
the script.

You can (will) still keep all the downloaded files & patches.

mfg
Bingo

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.