Problem mit dem "Script for building AVR-GCC 4.2.2 on Linux"

Tux Gast #1042242
Lesenswert?
• ▲
▼ 
Hallo,

ich versuche mit dem Bingo600 Script

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631

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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jörg W. Moderator Persönliche Seite #1042422
Lesenswert?
• ▲
▼ 
Dein lex muss irgendwie kaputt sein.  Diese beiden Symbole sind
normalerweise im Parser definiert:
1
% nm ~/src/avrdude/libavrdude_a-lexer.o | fgrep -v ' U '

2
0000000000000870 t input

3
0000000000001740 r yy_accept

4
0000000000002200 r yy_base

5
0000000000000010 b yy_c_buf_p

6
0000000000000f80 r yy_chk

7
0000000000000400 T yy_create_buffer

8
0000000000000008 b yy_current_buffer

9
00000000000008a0 r yy_def

10
00000000000004e0 T yy_delete_buffer

11
0000000000000024 b yy_did_buffer_switch_on_eof

12
0000000000001e00 r yy_ec

13
00000000000001d0 t yy_fatal_error

14
00000000000001c0 t yy_flex_alloc

15
00000000000004d0 t yy_flex_free

16
0000000000000170 T yy_flush_buffer

17
0000000000000530 t yy_get_next_buffer

18
0000000000000000 t yy_get_previous_state

19
000000000000001c b yy_hold_char

20
0000000000000000 d yy_init

21
0000000000000390 T yy_init_buffer

22
0000000000000030 b yy_last_accepting_cpos

23
0000000000000028 b yy_last_accepting_state

24
00000000000000d0 T yy_load_buffer_state

25
00000000000007c0 r yy_meta

26
0000000000000020 b yy_n_chars

27
0000000000000000 r yy_nxt

28
0000000000000200 T yy_scan_buffer

29
00000000000002c0 T yy_scan_bytes

30
0000000000000370 T yy_scan_string

31
0000000000000018 b yy_start

32
0000000000000110 T yy_switch_to_buffer

33
0000000000000008 C yyin

34
                 ^^^^^^

35
0000000000000004 C yyleng

36
0000000000000960 T yylex

37
                 ^^^^^^^

38
0000000000000000 B yyout

39
0000000000000480 T yyrestart

40
0000000000000008 C yytext
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tux Gast #1044496
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 ?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #1044518
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tux Gast #1045372
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$
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #1045472
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):

1
make  all-recursive

2
bison -y -d -d config_gram.y

3
if test -f y.tab.h; then  to=`echo "config_gram_H" | sed  -e 'y/abcdefghijklmnopqrstuvwxyz/AB

4
CDEFGHIJKLMNOPQRSTUVWXYZ/'  -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`;  sed -e "/^#/!b" -e "s

5
/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

6
 cmp -s config_gram.ht config_gram.h; then  rm -f config_gram.ht ; else  mv config_gram.ht co

7
nfig_gram.h;  fi;  fi

8
if test -f y.output; then  mv y.output config_gram.output;  fi

9
sed '/^#/ s|y\.tab\.c|config_gram.c|' y.tab.c >config_gram.ct && mv config_gram.ct config_gram.c

10
rm -f y.tab.c

11
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

12
flex   lexer.l

13
sed '/^#/ s|lex.yy\.c|lexer.c|' lex.yy.c >lexer.c

14
rm -f lex.yy.c

15
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

16
...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tux Gast #1045618
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.
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
yalu Gast #1045669
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

1
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tux Gast #1046420
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tux Gast #1046488
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #1046587
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tux Gast #1047927
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 !
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bingo Gast #1063094
Lesenswert?
• ▲
▼ 
1
It depends.  Im Großen und Ganzen sollte es gehen.  Ich weiß nur nicht,

2
ob Bingo600 den schrägen Hack mit dem avr-size -C auch mit eingebaut

3
hat oder nicht.  Falls nicht, müsstest du den Aufruf von avr-size auf

4
-B abändern.


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

(Blushing....)

mfg
Bingo aka Bingo600
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bingo Gast #1063102
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 Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren