Hallo an alle!
wir sind jetzt auf ein weiteres Problem beim compilieren gestossen
nämlich das:
collect2: ld returned 1 exit status
make: *** [Technikerarbeit.elf] Fehler 1
Build failed with 1 errors and 3 warnings...
irgendeine datei fehlt dem Linker, aber es ist nicht ersichtlich welche
das sein soll oder kann! kann man das irgendwo auslesen oder kann einer
mal den code überfliegen und mir einen tip geben wo ich suchen kann!
MfG
Arne
also die 3 warnungen sind nicht benutzte definitionen und den fehler
zeigt es nicht an! das ist das komische an der ganzen sache! laut google
fehlen i.welche linkdateien! ich kann nachher mal die komplette logdatei
reinstellen!
"multiple definition of ..." ist ein Fehler, den der linker wirft
Davon gibt es nicht nur einen, sondern mehrere, nur kann das Studio die
linker-Fehlermeldungen nichta auswerten, und meldet daher nur die
"Nicht-Erfolsmeldung" des linkers als Fehler.
Also zeig mal deinen Code, da steckt der Wurm drin.
Oliver
>> ist keine Fehlermeldung, oder wie würdest du das sehen?>> Von wegen "keine Fehlermeldung vom Linker"
es sind 5 von den meldungen, nicht nur eine, deswegen bring ich das
nicht in zusammenhang!
in der datei hier ist der quellcode der SNAP.c
http://www.fotogalerie-neuffen.de/Snap.pdf
Arne Pfäffle schrieb:>> Von wegen "keine Fehlermeldung vom Linker">> es sind 5 von den meldungen, nicht nur eine, deswegen bring ich das> nicht in zusammenhang!
Der Linker meldet an make zurück, dass er das EXE nicht zusammenbauen
kann. Für make ist das 1 Fehler.
Arne Pfäffle schrieb:> in der datei hier ist der quellcode der SNAP.c>> http://www.fotogalerie-neuffen.de/Snap.pdf
Häng doch das C-File hier einfach als Attachment an!
Das ist für dich einfacher und für uns auch. Dann braucht kein Mensch
erst mal von irgendwoher ein File laden, den PDF Reader starten um dann
im PDF Reader mit untauglichen MItteln zu suchen.
Aber wahrscheinlich ist der Fehler sowieso in einem Header File zu
suchen, welches sowohl von snap.c als auch von Technikerarbeit.c
inkludiert wird.
Am schnellsten gehts, wenn du einfach alle *.c und alle *.h Files hier
hochlädst.
so das müsste jetzt alles an dateien sein!
die technikerarbeit.c ist noch nicht fertig, der eigentliche code fehlt
noch, das ist jetzt nur zum testen!
µC: Atmega 328P
Gruß
Arne
Karl Heinz Buchegger schrieb:> Für make ist das 1 Fehler.
Nein, es ist ein "error code 1", also ein Programmende mit
Fehlerstatus. Nur Status 0 wäre fehlerfrei.
Nein, der Linker ändert seinen error code nicht in Abhängigkeit
davon, wie viele Fehler er entdeckt hat.
Peter II schrieb:> Karl Heinz Buchegger schrieb:>> irrtümlich einen#include "snap.c">> stehen hast?>> sehr gut Herr Buchegger..>> siehe anhänge.
mit der Zeit kennt man ja seine Pappenheimer :-)
Karl Heinz Buchegger schrieb:> Peter II schrieb:>> Karl Heinz Buchegger schrieb:>>> irrtümlich einen#include "snap.c">>> stehen hast?>>>> sehr gut Herr Buchegger..>>>> siehe anhänge.>> mit der Zeit kennt man ja seine Pappenheimer :-)
ja des ist net ganz so die feine englische art :-) aber mit snap.h hat
es net so ganz geklappt das ist n bissel komisch!
und n bissel zu meiner verteidigung: ich bin avr neuling hatte bis jetzt
nur erfahrung mit ride7! das ist mein erster anlauf damit!
p.s. das tutorial hab ich gemacht aber das beantwortet au net alle
fragen :-)
Arne Pfäffle schrieb:> Karl Heinz Buchegger schrieb:>> Peter II schrieb:>>> Karl Heinz Buchegger schrieb:>>>> irrtümlich einen#include "snap.c">>>> stehen hast?>>>>>> sehr gut Herr Buchegger..>>>>>> siehe anhänge.>>>> mit der Zeit kennt man ja seine Pappenheimer :-)>> ja des ist net ganz so die feine englische art :-) aber mit snap.h hat> es net so ganz geklappt das ist n bissel komisch!
Dann muss man dem eben nachgehen.
Aber ein 'hat nicht so geklappt' durch eine Wischi-Waschi-Lösung zu
ersetzen, ist keine Lösung. Du siehst ja, was dabei rauskommt.
snap.h ->> snap_header.h
snap.c ->> snap.h
in der neuen snap.h den neuen header einbinden und diesen in
Technikerarbeit.c einbinden und dann kam der log!
ob es daran was auszusetzen gibt wollt ich eigentlich wissen?
eigentlich ist die lösung relativ simpel, aber wenn man sich in dem
problem verrennt wie ich heute mittag, dann sieht man den wald eben
nicht mehr... trotzdem danke für die hilfe und anregungen!
Gruß
Arne
Arne Pfäffle schrieb:> ob es daran was auszusetzen gibt wollt ich eigentlich wissen?
Na, ja.
Die Warnungen müssen noch weg.
Am besten behandelst du Warnungen als ob sie Fehler wären und änderst
deinen Code so, dass die Ursache der Warnung behoben wird. Was für
geübte Profis völlig normal ist (Compiler werden so eingestellt, dass
sie Warnungen wie Fehler behandeln, sprich: sie erzeugen dann kein
Object-File), sollte dir als Neuling recht sein.
Arne Pfäffle schrieb:> ok, dann mach ich mich daran, das einzigste was jetzt noch kommt sind> unbenutzte variablen>> und wenn ich das mit dem extern mach, kommen 34 fehler mit>>
Du hast den 2.ten Teil des Vorschlags nicht umgesetzt:
Die Variablen müssen natürlich irgendwo sein! extern sagt ja nur: "Es
gibt sie irgendwo". Nur wo?
In deinem snap.C-File!
Dort müssen die alle rein.
(Zusatz: Link nicht gelesen?)
Johann L. schrieb:> Oje, #define EXTERN extern. Das muss auch mal jemand überarbeiten!
Man sollte zumindest erwähnen, dass dies nicht jeder als guten Stil
empfindet, auch wenn es formal daran nichts auszusetzen gibt.
Krapao schrieb:> Ist u.a. dafür nicht die Diskussionsseite da?
Jein. Die Diskussionsseite liest sich nicht jeder durch. Eine
derartige Implementierung empfindet manch einer aber schon als
reichlich verquer (das Headerfile wird nur durch das Vorhandensein
eines vorher definierten Makros plötzlich vom Deklarations- zum
Definitionsmodul umfunktioniert), dass man dies schon im Artikel
selbst kurz erwähnen sollte, wobei für umfangreichere Argumentationen
natürlich auf die Diskussionsseite verwiesen werden kann.
Thread beobachten
Seitenaufteilung abschalten