mikrocontroller.net

Forum: Compiler & IDEs MSPGCC: Komische Compiler-Fehler...


Autor: Philipp Burch (philipp_burch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich hab' merkwürdige Probleme mit dem MSPGCC-Compiler. Ich bin 
eigentlich dabei, die EFSL (Embedded file system library) für den MSP430 
umzuschreiben. Im grossen und ganzen ja kein Problem, aber es scheint 
auf dieser Welt keinen MSP430-Compiler zu geben, der das Ding 
kompilieren kann. IAR hat so seine Probleme, gemäss CCE ist so ziemlich 
jede Zeile falsch und der MSPGCC liefert Fehler, die irgendwie einfach 
net logisch sind. Beispiel:
""tmp" undeclared" Code:
 FAT_File *tmp;
Hallo? tmp wird ja in eben dieser Zeile deklariert!
Allerdings ist das nur die Spitze des Eisbergs. Die Probleme scheinen 
alle in den Dateien "helper.h" und "helper.c" (im nächsten Post 
angehängt) zu sein.
Hier mal die Fehlermeldungen und Warnungen:

----------------------------------
Severity and Description  Path  Resource  Location  Creation Time  Id
`f' undeclared (first use in this function)  efsl_msp430/src/interfaces 
helper.c  line 50  1161634750093  19563
warning: implicit declaration of function `fclose' 
efsl_msp430/src/interfaces  helper.c  line 68  1161634750093  19570
`FAT_File' undeclared (first use in this function) 
efsl_msp430/src/interfaces  helper.c  line 59  1161634750093  19566
`file' undeclared (first use in this function) 
efsl_msp430/src/interfaces  helper.c  line 75  1161634750093  19573
`filename' undeclared (first use in this function) 
efsl_msp430/src/interfaces  helper.c  line 50  1161634750093  19565
`SEEK_END' undeclared (first use in this function) 
efsl_msp430/src/interfaces  helper.c  line 75  1161634750093  19574
`tmp' undeclared (first use in this function) 
efsl_msp430/src/interfaces  helper.c  line 59  1161634750093  19567
syntax error before '*' token  efsl_msp430/inc/interfaces  helper.h 
line 45  1161634750093  19559
syntax error before '*' token  efsl_msp430/inc/interfaces  helper.h 
line 47  1161634750093  19560
syntax error before '*' token  efsl_msp430/src/interfaces  helper.c 
line 48  1161634750093  19562
syntax error before '*' token  efsl_msp430/src/interfaces  helper.c 
line 71  1161634750093  19571
warning: implicit declaration of function `fgetc' 
efsl_msp430/src/interfaces  helper.c  line 66  1161634750093  19569
warning: implicit declaration of function `fopen' 
efsl_msp430/src/interfaces  helper.c  line 50  1161634750093  19564
warning: implicit declaration of function `fseek' 
efsl_msp430/src/interfaces  helper.c  line 75  1161634750093  19572
warning: implicit declaration of function `ftell' 
efsl_msp430/src/interfaces  helper.c  line 76  1161634750093  19575
warning: implicit declaration of function `perror' 
efsl_msp430/src/interfaces  helper.c  line 42  1161634750093  19561
warning: ISO C89 forbids mixed declarations and code 
efsl_msp430/src/interfaces  helper.c  line 60  1161634750093  19568
-------------------------------



Anscheinend hat er Probleme mit den Deklarationen der folgenden beiden 
Funktionen und ihren Prototypen:
void Fopen(FAT_File** f,eint8* filename)
{
 *f=fopen(filename,"r+");
 if(*f==NULL){
  perror("Fopen: ");
  exit(-1);
 }
}
und
int getFileSize(FAT_File* file)
{
 eint32 c=0;
 
 fseek(file,0,SEEK_END);
 c=ftell(file);
 return(c);
}
Auch in den anderen Funktionen in diesen Dateien wirft er Fehler, die 
hängen aber möglicherweise mit diesen beiden Funktionen zusammen...

Ich wäre sehr froh, wenn mir jemand sagen könnte, was an dem Code denn 
angeblich falsch ist, bzw. wie ich es hinkriege, dass der MSPGCC diese 
Lib kompilieren kann. Bin net so der C-Hai, daher fallen mir 
Ungereimtheiten auch net wirklich auf. Wär' ja alles verständlich, wenn 
es nicht etwas wäre, was bestimmt schon viele Male von anderen Compilern 
erfolgreich kompiliert wurde...

Ich hoffe mir kann jemand helfen und danke im Voraus
Philipp

Autor: Philipp Burch (philipp_burch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch die "helper.c".

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (...) und der MSPGCC liefert Fehler, die irgendwie einfach
> net logisch sind. Beispiel:
> ""tmp" undeclared" Code:
>
> FAT_File *tmp;
>
> Hallo? tmp wird ja in eben dieser Zeile deklariert!

Ja, tmp wird da deklariert. Aber was ist "FAT_File"? Wo ist das 
deklariert?


Im übrigen solltest Du Fehlermeldungen/Warnungen immer von "oben herab" 
betrachten, der erste Fehler ist oft der entscheidende und der Rest sind 
nur Folgefehler.

Ohne debug.h und types.h zu sehen, kann man aber nur wenig Schützenhilfe 
geben.

Autor: Philipp Burch (philipp_burch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Oh sorry, hier sind mal alle Dateien. Geändert habe ich eigentlich nix, 
das ganze Ding ist der Code von der EFSL bei SourceForge. Ausser 
FAT_File, das hab' ich so beannt, davor hiess es einfach "File". Ich 
hab' den Namen geändert, um Probleme mit evtl. gleichheissenden 
Bezeichnern zu vermeiden. Hat leider auch nix geholfen, der Fehler ist 
der gleiche wie davor.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwar bindet helper.c die Datei helper.h ein, aber die wiederum bindet 
keine Headerdatei ein, in der der Typ "FAT_File" deklariert wird.

Deklariert wird der zweimal in efs.h und in file.h

Du solltest Dir das mit dem wer-bindet-wann-wo-welche-Headerdatei-ein 
nochmal genauer ansehen bzw. sinnvoll überarbeiten.

Warum bindest Du "helper.h" nur in "helper.c" und sonst nirgends ein? 
Warum bindest Du die Headerdateien, die Du in "helper.h" einbindest, 
nicht gleich in "helper.c" ein, wo sie auch hingehören?

Autor: Philipp Burch (nicht angemeldet) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry wegen dem kurzen Post gestern, war etwas im Stress.
Also:
Du meinst also, dass er FAT_File nicht findet und als Fehler angibt, 
"tmp" sei nicht deklariert? Ist das ein Fehler des Compilers oder sowas? 
Allerdings ist der Fehler, dass FAT_File nicht deklariert ist ja etwas 
weiter unten...
Das "wer-bindet-wann-wo-welche-Headerdatei-ein" werde ich mir noch 
ansehn, scheint so als wäre das irgendwie etwas verkehrt. Was wäre denn 
eine gute Variante, damit sicher überall alles eingebunden wird? Macht 
es Sinn, alle Dateien von einer Datei aus einzubinden (Includes.h oder 
sowas) und die einfach überall einzubinden, oder ist das nicht so 
geschickt?

Jedenfalls schonmal danke für deine Hilfe, ich weiss jetzt jedenfalls 
schonmal, was ich mir genauer anschauen muss.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was wäre denn eine gute Variante, damit sicher überall alles eingebunden
> wird?

Ganz einfach. Jede Einheit, egal ob Header oder C-File bindet
die Header mit ein, die sie selber braucht.

Wenn also in einem helper.h eine struct FAT_file benutzt
wird, und diese struct FAT_file in einem anderen Header
File file.h deklariert ist, dann bindet helper.h die file.h
mit ein.
Dadurch ist sichergestellt, dass derjenige, der seinerseits
helper.h einbindet sich nicht darum kümmern muss, welcher
Rattenschwanz an includes noch nötig ist um helper.h includen
zu können.

Dabei kann es natürlich zu dem Fall kommen, dass ein und dieselbe
Header-Datei bei der Compilierung eines *.c Files mehrfach
includiert wird. Die dabei entsehenden Schwierigkeiten kann
man mit Include-Guards umgehen:
Jede Header-Datei beginnt und endet so (am Beispiel einer
helper.h)

helper.h:
*********

#ifndef HELPER_H_INCLUDED
#define HELPER_H_INCLUDED

#include "file.h"

// Hier kommt dann der Inhalt der helper.h

#endif

file.h:
*******

#ifndef FILE_H_INCLUDED
#define FILE_H_INCLUDED

struct FAT_file {
  // bla bla
};

#endif


Damit ist sichergestellt, dass der Compiler bei der Compilierung
eines *.c Files:

helper.c:
*********

#include "helper.h"
#include "file.h"

void FAT_file was_weis_ich()
{
}

den Inhalt von file.h nur ein einziges mal zu Gesicht kriegt,
auch dann wenn helper.c die file.h inkludiert und über den
Umweg über helper.h nochmal.

Aber das Grundprinzip ist: Jeder bindet das ein, was er braucht.
Nicht mehr und nicht weniger.
Solche Alles-inkludieren-Rundumschlag-Header haben sich auf
lange Sicht nicht bewährt.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu deinem Fehlermeldungen:
Interessant ist im Regelfall nur die erste Fehlermeldung.
Wird die korrigiert, so fallen oft eine ganze Menge anderer
Fehler weg. Wenn der Compiler durch einen Fehler 'den Faden verloren'
hat, dann kommen oft ne Menge Folgefehler.

> FAT_File *tmp;
> Hallo? tmp wird ja in eben dieser Zeile deklariert!

Die erste Fehlermeldung war:

>efsl_msp430/src/interfaces  helper.c  line 68  1161634750093  19570
> `FAT_File' undeclared (first use in this function)

Der Compiler konnte also mit FAT_File nichts anfangen. Er weis
nicht was das ist. Folgerichtig kann er auch keine Variablen
vom Typ FAT_File anlegen, da er ja nicht weis wieviele Bytes
dafür zu reservieren sind. Noch nicht mal einen Pointer. FAT_File
könnte ja auch ein Funktionstyp sein und niemand garantiert, dass
Funktionspointer und Datenpointer dieselbe Länge haben.
Da er also die Variable tmp nicht erzeugen kann, sind daher alle
Verwendungen von tmp ebenfalls illegal. Siehst du wie Eins zum
Anderen führt? Wie gesagt:
Konzentrier dich auf den ersten Fehler oder zumindest: frage
dich bei weiteren Fehlermeldungen ob das nicht ein Folgefehler
sein könnte, der durch Behebung eines früheren Fehlers ebenfalls
verschwindet.

Und schrecke nicht vor vielen Fehlermeldungen zurück: 90%
davon sind meist Folgefehler. Korrigiert man den ersten Fehler
so verschwinden 100 von den 120 Fehlermeldungen ganz von alleine.




Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> warning: implicit declaration of function `fclose'

Diese Warnung (und alle anderen in weiterer Folge) allerdings
solltest du ernst nehmen.
Entweder hat da wer vergessen stdio.h zu inkludieren (in dem
Fall sollte man ihm das Compilermanual mal um die Ohren hauen,
dass er solche Warnungen ignoriert), oder mit deinem Compiler-
Setup stimmt was nicht.

Autor: Philipp Burch (philipp_burch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also, hab' jetzt nochmal bissle rumprobiert. Ich hab' den Code nun 
soweit, dass ich bei einem Fehler angelangt wird (Lag wirklich an den 
Includes...). Allerdings wird's langsam relativ strub. Je nachdem wie 
fest ich optimieren lasse (O0 - O3) hat er andere "internal error"s. Bei 
O0 und O1 (Das erste Zeichen ist ein grosses o):
make: *** [src/debug.o] Error 1    efsl_msp430  line 0

Bei O2:
internal error: Segmentation fault  efsl_msp430/src  fs.c  line 179
make: *** [src/debug.o] Error 1    efsl_msp430  line 0

Und schliesslich bei O3:
Internal compiler error in verify_local_live_at_start, at flow.c:586 
efsl_msp430/src  fs.c  line 60
make: *** [src/debug.o] Error 1    efsl_msp430  line 0
Wenn ich ihn mit der gleichen Einstellung nochmal aufrufe gibt's auch 
noch folgende Warnung:
Error launching external scanner info generator (gcc -E -P -v -dD 
C:/Programme/eclipse/workspaces/.metadata/.plugins/org.eclipse.cdt.make. 
core/specs.c)     efsl_msp430  Unknown

In fs.c (Im Anhang) besteht Zeile 60 sowie 179 aus
}
Nix weiter, bei beiden ist es das Ende einer Funktion. Allerdings nicht 
der gleichen...

Die beiden "internal error"s könnten ein Bug des Compilers sein, muss 
ich dessen Erbauern wohl mal schreiben. Aber der andere Fehler "Error 1" 
ist eigenartig. In der Konsole steht da sowas:

--------------------
'Building file: ../src/debug.c'
'Invoking: mspgcc GCC C Compiler'
msp430-gcc -I"C:\Programme\mspgcc\msp430\include" -O0 -g3 -Wall -c 
-fmessage-length=0 -mmcu=msp430x169 -o"src/debug.o" "../src/debug.c" && 
\
  echo -n 'src/debug.d' src/ > 'src/debug.d' && \
  msp430-gcc -MM -MG -P -w -I"C:\Programme\mspgcc\msp430\include" -O0 
-g3 -Wall -c -fmessage-length=0 -mmcu=msp430x169  "../src/debug.c" >> 
'src/debug.d'
Das System kann den angegebenen Pfad nicht finden.
make: *** [src/debug.o] Error 1
--------------------

Und das mehr oder weniger für alle Dateien. Manchmal für ein paar mehr, 
manchmal weniger...

Ich blick's echt nicht mehr... Was kann das sein? Und WELCHEN Pfad kann 
er denn nicht finden? Ich weiss ja nicht was er mit 'src/debug.xy' 
anstellt, aber ich nehme schon an, dass er da im richtigen Verzeichnis 
sucht. Ansonsten existieren die Verzeichnisse ja...

Kann mir da auch jemand helfen?

Autor: Philipp Burch (philipp_burch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Weiss denn niemand was zu den Fehlermeldungen? Ich komm' echt nimmer 
nach. Ich hab' das ganze Ding jetzt mal mit IAR kompiliert und DAMIT 
GEHT'S! Aber warum? Das heisst ja, dass der Code jetzt in Ordnung ist, 
was hat der mspgcc also für komische Probleme damit?!
Im Anhang mal die gesamte Ausgabe der Konsole.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> -o"src/plibc.o" "../src/plibc.c"

Das sieht seltsam aus. Das die *.c Files auf einem Verzeichnis
namens src liegen, ist noch logisch. Aber dass die Object-Files
auf ein anderes src Verzeichnis gehen, ist schon seltsam:
Zum einen ist es nicht dasselbe Verzeichnis, zum anderen heist
es ebenfalls src. Und das ist schon eher ungewöhnlich. Selbiges
mit den *.d files.

Deine Verzeichnis-Struktur muesste also so aussehen:

           was_weis_ich
            /           \
          src (1)       Projekt (3)
                          \
                         src (2)

(1) hier muessten die *.c Files zu finden sein
(2) hier enstehen die *.o und *.d Files
(3) hier liegt das makefile

Hast du die Struktur? Ich könnte mir vorstellen, dass
es das Verzeichnis src (2) nicht gibt und sich der Compiler
beschwert, dass er die Ausgabefiles nicht erzeugen kann.

Zu den internal Compiler-Errors:
Sowas ist immer blöd. Da hilft nur mit dem Code etwas spielen.
Dinge umstellen und hoffen, dass du das richtige erwischt.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, die Verzeichnisstruktur sieht so aus:

          Projekt-Ordner
           /  |       \
          /   |        \
        src  inc      Debug
        *.c  *.h      /   \
                     /     \
                   src  makefiles
                   *.o    *.mk

So gesehen eigentlich durchaus existierend, aber ob der da wirklich 
immer am richtigen Ort sucht? Und wie könnte man sowas denn umstellen?

>Zu den internal Compiler-Errors:
>Sowas ist immer blöd. Da hilft nur mit dem Code etwas spielen.
>Dinge umstellen und hoffen, dass du das richtige erwischt.

Na du machst mir Mut ;)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Burch wrote:
>  *f=fopen(filename,"r+");

Das was du da kompilierst macht auf einem MSP430 keinen Sinn, das ist 
das "Hardwarelayer" für einen PC wo fopen & Co. zur Verfügung stehen.

Meine Meinung: EFSL ist unübersichtlich, unnötig komplex, schlecht 
dokumentiert, und hat ein zweifelhaftes API. Nimm lieber 
http://elm-chan.org/fsw/ff/00index_e.html.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hui, danke für den Link Andreas! Das sieht schonmal sehr gut aus! 
Irgendwann hatte ich das schonmal gesehen, hab's aber dann leider wieder 
vergessen. Hätte mir womöglich einiges an Arbeit erspart, mal sehn...

PS: Sorry wegen dem falschen Forum.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hab's jetzt mit dem Code vom Elm-Chan gemacht. Sieht gut aus! War 
noch ein ordentlicher Kampf, bis ich den Debugger zum Laufen gekriegt 
hab'. Vielleicht sollte man im Artikel noch erwähnen, dass der u.U. 
nicht funktioniert, wenn die Pfade zu lang sind und/oder Leerzeichen 
beinhalten. Auf einem "neuen" Laufwerk ohne langen Pfad ging's dann 
plötzlich.

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.