Announcement: there is an English version of this forum on Guten Tag, ich wende mich mit einem für mich unlösbaren Problem an euch. Wahrscheinlich kann ich das Problem nicht einmal richtig beschreiben. Ich versuche es trotzdem mit diesem kurzen Vorspann: Wir haben vor über 15 Jahren für eine Landwirtschaftliche Maschine mit einer Rexroth Steuerung RC36-20/30 die Software entwickelt. Damals hat uns jemand auf einem Rechner (Windows XP) die Entwicklungsumgebung eingerichtet und wir konnten eine für uns zufriedenstellende Software in c entwickeln. Unsere Applikation bestand nur aus zwei Files (application.c .h und hydraullik.c .h). Mittels des anhängenden make Files wurden diese compiliert, gelinkt und in eine Hexdatei gewandelt, die dann in das Zielsystem übertragen wurde. Nach nun über 15 Jahren mussten wir die Maschine demontieren und neu aufbauen, wobei wir auch eine kleine Softwaremodifikation vornehmen wollten. Und jetzt kommt das Problem: Der Rechner auf dem sich die Entwicklungsumgebung befindet wurde in der Zwischenzeit für absolut nichts verwendet. Wenn ich aber heute das make File ausführe, bekomme ich die Fehlermeldung: syntax error near unexpected token -Wl,-( obj/application.o obj/hydraulik.o ….. Ich denke, dass es etwas mit dem Linker zu tun hat, den die obj Dateien werden erstellt. Was zum Teufel ist das. Der Rechner ist an keinem Netzwerk, kann sich somit eigentlich nichts seltsames irgendwo eingefangen haben und alle Dateien die irgendwie zur Entwicklungsumgebung gehören haben alle ein Datum von 2008 und 2009. Dieses Aufsetzen von Entwicklungsumgebungen ist für mich leider ein völlig undurchschaubares Buch mit sieben Siegeln. Vielleicht kann mir jemand einen Tipp geben, warum es zu dieser Fehlermeldung kommt. Entschuldigt bitte meine wahrscheinlich sehr laienhafte Fehlerbeschreibung. Wenn man damit nichts anfangen kann, möge der Admin meine Anfrage bitte löschen. Herzlichen Dank und viele Grüße Michael
Michael schrieb: > syntax error near unexpected token -Wl Wie führst du das Makefile denn aus? Das ist ein Makefile. Dass muss man mit "make" starten, nicht versuchen, es direkt irgendwie als Batchfile oder dergleichen zu starten. Das zu benutzende "make" muss auch noch zum Makefile passen, leider gibt es ein paar Variationen in der Syntax zwischen den verschiedenen Dialekten von "make".
1 | $(MODULE_NAME).elf: $(OBJECTS) |
2 | @echo $(LD) $(OBJECTS) -o $(OUTPUT_PATH)/$(MODULE_NAME).elf |
3 | @$(LD) -Wl,-( $(OBJECTS) $(LIBRARIES) -Wl,-) -o $(OUTPUT_PATH)/$(MODULE_NAME).elf\ |
4 | $(LINKER_LNK) $(LINKER_FLAGS) |
5 | #@$(LD) $(OBJECTS) $(LIBRARIES) -o $(OUTPUT_PATH)/$(MODULE_NAME).elf \
|
6 | #$(LINKER_LNK) $(LINKER_FLAGS)
|
Die Fehlermeldung kommt aus der Zeile die mit "@$(LD)" beginnt. Diese Syntax verstehe ich nicht. Testweise würde ich diese Zeile und die nachfolgende Zeile mit einem "#" am Beginn der Zeile auskommentieren und stattdessen die vorhandenen "#" in den beiden Zeilen darunter entfernen.
Jörg W. schrieb: > Michael schrieb: >> syntax error near unexpected token -Wl > > Wie führst du das Makefile denn aus? > > Das ist ein Makefile. Dass muss man mit "make" starten, nicht versuchen, > es direkt irgendwie als Batchfile oder dergleichen zu starten. > > Das zu benutzende "make" muss auch noch zum Makefile passen, leider gibt > es ein paar Variationen in der Syntax zwischen den verschiedenen > Dialekten von "make". Das Makefile wird mit make -f makefile.mak in einem DOS Fenster gestartet. Das komische ist, dass ich an den Files ja nichts geändert habe.
Michael schrieb: > Das komische ist, dass ich an den Files ja nichts geändert habe. Dann klingt es danach, als wäre mehr als ein Programm "make" auf dem Computer, und es wird das Falsche davon benutzt. Dafür ist die Variable PATH zuständig. Mach doch mal ein
1 | echo %PATH% |
und schau, welche Elemente da alles so drin sind.
Michael schrieb: > make -f makefile.mak Und wo ist dieses makefile.mak? Gepostet hast Du eine Datei mit Namen makefile_LT.txt
Klaus schrieb: >
1 | > $(MODULE_NAME).elf: $(OBJECTS) |
2 | > @echo $(LD) $(OBJECTS) -o $(OUTPUT_PATH)/$(MODULE_NAME).elf |
3 | > @$(LD) -Wl,-( $(OBJECTS) $(LIBRARIES) -Wl,-) -o |
4 | > $(OUTPUT_PATH)/$(MODULE_NAME).elf\ |
5 | > $(LINKER_LNK) $(LINKER_FLAGS) |
6 | > #@$(LD) $(OBJECTS) $(LIBRARIES) -o $(OUTPUT_PATH)/$(MODULE_NAME).elf \ |
7 | > #$(LINKER_LNK) $(LINKER_FLAGS) |
8 | >
|
> > Die Fehlermeldung kommt aus der Zeile die mit "@$(LD)" beginnt. > Diese Syntax verstehe ich nicht. > Testweise würde ich diese Zeile und die nachfolgende Zeile mit einem "#" > am Beginn der Zeile auskommentieren und stattdessen die vorhandenen "#" > in den beiden Zeilen darunter entfernen. O.k. dann war ich schon mal nicht ganz verkehrt. Die beiden oberen aktiven Zeilen sind die Ursprünglichen. Die auskommentierten habe ich geschrieben und probiert. Es scheint als würde der Linker dann durchlaufen, es kommt aber dann bei der Erstellung der Hexen Datei eine für mich nicht zu deutende Fehlermeldung. Es wird aber tatsächlich eine hex Datei erstellt. Da ich leider keine vor 15 Jahrer erzeugte hex Datei habe, die ich dann vergleichen könnte, ist es mir zu heiss die neu erstellt und vielleicht nicht lauffähige Datei ins Zielsystem zu schreiben. Damit würde ich mir die Maschine gnadenlos lahmlegen. Da ich das makefile ja nicht verändert habe und es früher damit funktionierte muss irgend etwas anderes im Argen liegen. Herzlichen Dank, dass ihr euch über mein Problem Gedanken macht.
Klaus schrieb: > Michael schrieb: >> make -f makefile.mak > > Und wo ist dieses makefile.mak? > Gepostet hast Du eine Datei mit Namen makefile_LT.txt Sorry, das macht die Sache jetzt unnötig unübersichtlich. Das war nur ein hin und herkopieren von dem alten Rechner mit dem Ziel die ursprüngliche Datei sicher nicht zu verändern. Das gepostete makefile_LT.txt ist identisch mit makefile.mak
Jörg W. schrieb: > Michael schrieb: >> Das komische ist, dass ich an den Files ja nichts geändert habe. > > Dann klingt es danach, als wäre mehr als ein Programm "make" auf dem > Computer, und es wird das Falsche davon benutzt. Dafür ist die Variable > PATH zuständig. Mach doch mal ein > > echo %PATH% > > und schau, welche Elemente da alles so drin sind. Oooo, das könnte ein heißer Tipp sein. Da werde ich morgen früh gleich einmal darann gehen. Besten Dank
Als allererstes würde ich folgendes tun: - das aktuelle Programm von der Maschine runterladen, sofern möglich - zum Vergleich mit dem neu erzeugten File (VOR der Softwaremodifikation) und als Sicherheitskopie - ein Snapshot von der Entwicklungsmaschine erstellen und diesen archivieren, BEVOR du irgendetwas daran änderst.
Noch folgender Hinweis: Natürlich ist auf der Maschine nicht das HEX-File, sondern eine Binärdatei. Aber das lässt sich umwandeln und - falls es Unterschiede gibt - auch dekompilieren und vergleichen.
Michael schrieb: > unexpected token -Wl,-( obj/application.o obj/hydraulik.o ….. Variable LD ist nicht gesetzt. Sie sollte den Namen (und pfad) zu deinem Linker enthalten. z.B. LD=/usr/bin/ld Warum ist LD nicht gesetzt ? Unter bash wäre sie. Aber du hast XP. Eventuell muss man vor dem Aufruf von make ein 'Umgebung aufsetzen' batch-File aufrufen oder ein CMD Fenster. Unzer VS2012 heisst das vsvars32.bat wenn also nur ein Compiler installiert ist rufe VSVARS auf, dann erst make (mit unmodifizierten batch file) Es gibt auch ein CMD Fenster Kommando im Startmenü von VisualStudio das gleich die Umgebung setzt. Klaus schrieb: > Diese Syntax verstehe ich nicht. Warum gibst du dann (unsinnige) tips ? @ heisst nicht echoen, $(LD) setze variable LD ein
LD muss auf den compiler, hier GCC, zeigen. Das sieht man an "-Wl". Es ist schon seit Ewigzeiten üblich den Linker nicht direkt aufzurufen sondern über den GCC, dann stimmen automatisch auch die Pfade zu den gcc Bibliotheken.
Aber CC und LD sollte normalerweise eben auch das Make selbst setzen.
Jörg W. schrieb: > Aber CC und LD sollte normalerweise eben auch das Make selbst setzen. Ja so kenne ich das auch. Möglicherweise wird das hier aber in dem "Microsoft" Style gemacht. Da muss man zuerst eine ".bat" starten, die setzt dann die ganzen Variablen. Kenne das vom Visual C compiler so.
Herzlichen Dank für eure ganzen Infos. Bin da einfach nicht so fitt, dass ich jetzt gleich alle Empfehlungen umsetzen kann. Die Sache mit den möglicherweise mehrfach vorhanden make.exe verstehe ich noch am besten und siehe da, es gibt zwei make.exe in verschiedenen Verzeichnissen. Wenn ich das make verschiebe von dem ich meine es ist das was ich brauche, läuft die Kiste trotzdem durch. Ich greife also auf ein make zu, auf das ich es nicht erwartet habe. Tausche ich die make.exe läuft es mit der bekannten Fehlermeldung durch. Denke, da stimmt irgend etwas mit den Pfaden grundsätzlich nicht (mehr). Eine Fehlersuche erscheint mir wegen meines fehlenden know how nun doch immer schwierige. Ich versuche es noch einmal bei einem unserer IT Experten. Mit den Erkenntnissen durch euch, bin ich optimistisch, dass wir da weiter kommen. Werde berichten. Viele Dank und Grüße Michael
:
Bearbeitet durch User
Michael B. schrieb: > LD=/usr/bin/ld Zum Linken will man in 99.9% der Fälle den Compilertreiber verwenden, also gcc für C-Cprogramme und g++ für C++ Programme. Und offenbar erwartet das Makefile LD=gcc o.ä weil -Wl KEINE Linker-operion ist.
Michael schrieb: > Eine Fehlersuche erscheint mir wegen meines fehlenden know how nun doch > immer schwierige. Brauchst du auch nicht. Du kannst das Make, mit dem es läuft, einfach mit einem absoluten Pfadnamen aufrufen. Geh in das Verzeichnis mit deinem Makefile, und dort
1 | C:\wo\auch\immer\das\ist\make -f makefile.mak |
Angehängte Dateien:
-
Fehlermeldung.JPG
160 KB
Jörg W. schrieb: > Michael schrieb: >> Eine Fehlersuche erscheint mir wegen meines fehlenden know how nun doch >> immer schwierige. > > Brauchst du auch nicht. Du kannst das Make, mit dem es läuft, einfach > mit einem absoluten Pfadnamen aufrufen. > > Geh in das Verzeichnis mit deinem Makefile, und dort > C:\wo\auch\immer\das\ist\make -f makefile.mak Hallo, bin wieder aus der Werkstatt zurück und tatsächlich es läuft jetzt besser. Es gibt jetzt nur noch eine make.exe und das wohl auch an der richtigen Stelle. Erzeugt werden jetzt insgesamt vier Dateien: Eine MAP Datei: appl_RC30-00D3 Eine Elf-Datei: appl_RC30-00D3.elf und zwei O-Dateien: application und hydraulik Das sieht jetzt ja schon mal ganz gut aus. Ich denke jetzt fehlt nur noch die .hex Datei. Vor der steht aber wohl noch die, für mich natürlich wieder völlig kryptische, Fehlermeldung. Vielleicht hat ja noch jemand einen Tipp und ich schaffe diese Hürde auch noch. Über die ersten habt ihr mich super katapultiert. Dafür euch allen herzlichen Dank. Hänge das makefile, die compiler_settings und die Fehlermeldung an.
Da sind mehrere Syntaxfehler in dem Makefile. Ich habe mal versuch es zu korrigieren. Da haben Leerzeichen gefehlt, teilweise waren unnötige Backslashes am Zeilenende. Es gab auch leere Zeilen die mit einem Tabulator angefangen haben. Zeilen mit Tabulator am Anfang haben eine Bedeutung in Make und sind nicht gleichbedeutend mit Leerzeichen.
:
Bearbeitet durch User
Ist den die Lib die der Linker dazu linken soll auch am angegebenen Ort vorhanden? Weil die Meldung ist ja <<Datei nicht gefunden>>. "c:/WernerSteuerung/BODAS_C_API_V4_0/RC36_10_30/V1.01/Libs/lib_basic.a"
<<Datei nicht gefunden>> bezieht sich sehr wahrscheinlich auf diese vermurksten Zeilen in "makefile.mak" (das # am Anfang geht so nicht):
1 | #@$(LD) $(OBJECTS) $(LIBRARIES) -o $(OUTPUT_PATH)/$(MODULE_NAME).elf \ |
2 | #$(LINKER_LNK) $(LINKER_FLAGS) |
Das ist das, was CreateProcess() starten will und das geht natürlich schief (das #@ im Pfadnamen gehört da nicht hin). Make bricht hier also ab, die ".dump" und ".hex" Targets werden nicht mehr ausgeführt. Eventuell reicht es die obigen Zeilen in "makefile.mak" zu löschen.
:
Bearbeitet durch User
Dieter S. schrieb: > <<Datei nicht gefunden>> bezieht sich sehr wahrscheinlich auf > diese > vermurksten Zeilen in "makefile.mak" (das # am Anfang geht so nicht): > > #@$(LD) $(OBJECTS) $(LIBRARIES) -o $(OUTPUT_PATH)/$(MODULE_NAME).elf \ > #$(LINKER_LNK) $(LINKER_FLAGS) > > Das ist das, was CreateProcess() starten will und das geht natürlich > schief (das #@ im Pfadnamen gehört da nicht hin). > > Make bricht hier also ab, die ".dump" und ".hex" Targets werden nicht > mehr ausgeführt. Eventuell reicht es die obigen Zeilen in "makefile.mak" > zu löschen. Hurra Sucessfully completed! 12:11 Wahnsinn, die Kiste läuft wieder. Es waren, wie ihr mir richtig auf die Fährte geholfen habt, die zwei vorhandenen make.exe und der falsche Pfad und jetzt zum Schluss die oben zitierten zwei Zeilen. Diese gelöscht und das Ding läuft durch. Tausend Dank an euch alle für die super tolle Hilfe. Viele Grüße und herzlichen Dank, Michael
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.