Normalerweise ist ja klar was "multiple definiton of main" bedeutet,
aber in dem Projekt gibt es nur eine main!
Diese befindet sich in der Datei startup.c und unter global function von
Codeblocks wird auch nur eine main angezeigt.
Mit eigenem makefile ist das Projekt compilier und linkbar, unter
Codeblocks zickt es rum.
Also was läuft da schief?
Oder habe ich was wichtiges bei Codeblocks übersehen?
Konsolenausgabe:
Linking native: mipstest
obj/Debug/src/System/startup.o: In function `main':
/src/System/startup.c:11: multiple definition of `main'
obj/Debug/src/System/startup.o:/src/System/startup.c:11: first defined
here
Weils so schön ist nochmal der selbe Fehler mit einem Array:
obj/Debug/src/System/startup.o: In function `main':
/src/System/startup.c:11: multiple definition of `font'
obj/Debug/src/System/startup.o:/src/System/startup.c:11: first defined
here
startup.c
Hab grade mal nachgesehen, das ist leider nicht die Lösung.
8x14_horizontal_LSB_1.h wird nur in startup.c includiert (da ist der
font enthalten)
startup.h wird von niemanden includiert, denn die main wird direkt aus
der start.s aufgerufen (diese initialisiert .data und .bss)
Zudem sind eh überall include guards in den Headern.
Mw E. schrieb:> Normalerweise ist ja klar was "multiple definiton of main" bedeutet,> aber in dem Projekt gibt es nur eine main!
Na, dann wirst Du dem Linker das object file wohl zwei mal vorgeworfen
haben ;-)
Also ICH geb dem Linker da ganix, das macht ja Codeblocks selber.
Der Compiler wirft die Objectfiles im Ordner obj/ ab und da guckt dann
der Linker nach.
startup.o ist natürlich einmal vorhanden.
Mw E. schrieb:> Also ICH geb dem Linker da ganix, das macht ja Codeblocks selber.
Naja, in irgend einer Form wirst Du ja definieren, wie Deine IDE
compiler und Linker aufruft (oft einfach auch dadurch, dass eine Datei
in der Datei-Übersicht einer IDE eingefügt wird). Zeig doch einfach mal
den Aufruf und den output von compiler und linker.
Wie in den Bildern vom vorherigen Post zu sehen gibt man für den Linker
nur den Pfad an in dem die .o Dateien liegen und Codeblocks baut daraus
den Linkeraufruf (siehe unten).
Ansonsten gibt man Codeblocks beim anlegen eines neuesn Compilers mit wo
denn die binarys von gcc und vom ld rumliegen und wie diese heißen.
Ein Compileraufruf vom Codeblocks sieht so aus, für jede Datei einzeln:
mips-elf-gcc -O2 -Wextra -Wall -g -march=mips1 -DPF_EMBEDDED -DEE_SCORE
-nostartfiles -g -c src/pForth/forth_sp2.c -o /src/pForth/forth_sp2.o
Beim Linkeraufruf gibt es auch nur eine startup.o
die "pf_main.o" heißt nur so, in dieser gibt es keine main() Funktion.
Linkeraufruf:
mips-elf-ld -Lobj/Debug/src -o bin/Debug/gdbtest
obj/Debug/src/Eliza/eliza.o
obj/Debug/src/GameOfLife/gameoflife.o
obj/Debug/src/Snake/snake.o
obj/Debug/src/Snake/soviet_snake.o
obj/Debug/src/System/div_u.o
obj/Debug/src/System/interrupt.o
obj/Debug/src/System/mult.o
obj/Debug/src/System/multu.o
obj/Debug/src/System/start.o
obj/Debug/src/System/startup.o
obj/Debug/src/Taschenrechner/statemachine.o
obj/Debug/src/Taschenrechner/statemachine_helper.o
obj/Debug/src/Treiber/EEPROM/EE_SPI_256.o
obj/Debug/src/Treiber/Tastatur/sp2io.o
obj/Debug/src/Treiber/UART_16C550/fifo.o
obj/Debug/src/Treiber/UART_16C550/uart_16c550.o
obj/Debug/src/Treiber/Videotreiber/videotreiber.o
obj/Debug/src/Tron/tron2p.o
obj/Debug/src/Viergewinnt/viergewinnt.o
obj/Debug/src/framebuffer.o
obj/Debug/src/highscorespeicher.o
obj/Debug/src/menu.o
obj/Debug/src/moon_buggy/buggy.o
obj/Debug/src/moon_buggy/game.o
obj/Debug/src/moon_buggy/ground.o
obj/Debug/src/moon_buggy/laser.o
obj/Debug/src/moon_buggy/level.o
obj/Debug/src/moon_buggy/meteor.o
obj/Debug/src/moon_buggy/mode.o
obj/Debug/src/moon_buggy/moonbuggy.o
obj/Debug/src/moon_buggy/queue.o
obj/Debug/src/pForth/csrc/pf_cglue.o
obj/Debug/src/pForth/csrc/pf_clib.o
obj/Debug/src/pForth/csrc/pf_core.o
obj/Debug/src/pForth/csrc/pf_inner.o
obj/Debug/src/pForth/csrc/pf_io.o
obj/Debug/src/pForth/csrc/pf_main.o
obj/Debug/src/pForth/csrc/pf_mem.o
obj/Debug/src/pForth/csrc/pf_save.o
obj/Debug/src/pForth/csrc/pf_text.o
obj/Debug/src/pForth/csrc/pf_words.o
obj/Debug/src/pForth/csrc/pfcompil.o
obj/Debug/src/pForth/csrc/pfcustom.o
obj/Debug/src/pForth/forth_bench.o
obj/Debug/src/pForth/forth_sp2.o
-T src/System/linkerscript.lds
-Map mapping.map
../mips-elf-gcc/mips-elf/lib/libm.a
../mips-elf-gcc/mips-elf/lib/libc.a
../mips-elf-gcc/mips-elf/lib/libnosys.a
../mips-elf-gcc/lib/gcc/mips-elf/4.8.0/libgcc.a
ich seh da was: "-Lobj/Debug/src"
Das ist der Suchpfad den ich eingetragen habe und Codeblocks sorgt für
die ganzen Pfade der .o Dateien dahinter.
Dann gibts natürlich was doppelt, ABER wenn ich -Lobj/Debug/src
entferne, dann findet der LInker seine Objectfiles nicht mehr.
Also ein Fehler gefixt und der nächste kommt geschwind.
mips-elf-ld: cannot find System/startup.o
Ich würde mal nach "startup.c" durch die sourcen suchen. Vielleicht hast
Du Dich irgend wo vertippt und #includes diese Datei. Ansonsten must Du
mal in den object files suchen, in welchem es dort noch eine Definition
von main() gibt (via grep einfach nach dem Text suchen und Dir dann die
Dateien, in denen der Text vorkommt noch mal mit nm genauer angucken).
Siehe mein Doppelpost hab ich das Problem durch deinen Hinweis mit dem
doppelt dem LInker übergeben schon gefunden.
Hab trotzdem nochmal nachgesehen, also die startup wird nirgends
eingebunden, nur die main aus der start.s angesprungen.
Ansonsten bringt grep nurnoch ein zusätzliches "irqmainhandler" zutage.
Hier nochmal der Post, jetzt will er nämlich garkeine o. Dateien mehr
finden:
Beitrag "Re: Code::Blocks multiple definiton of main"
Mw E. schrieb:> ich seh da was: "-Lobj/Debug/src"> Das ist der Suchpfad den ich eingetragen habe und Codeblocks sorgt für> die ganzen Pfade der .o Dateien dahinter.
Welches object gibt es denn dann doppelt eingebunden?
>> Dann gibts natürlich was doppelt,
?
Na wenn man dem Linker nen Suchpfad nach den Dateien gibt (aus dem
Codeblocks Suchpfad EInstellungen) UND die Dateien nochmal selber
(bekommt der Linker von Codeblocks), dann hat er die ja doppelt?
Bei startup.o (erste Datei) bricht der LInker dann direkt ab
Nur ohne "-Lobj/Debug/src" findet er dann garnichts mehr, aber die Pfade
stimmen.
Wenn ich mal in
https://sourceware.org/binutils/docs-2.27/ld/Options.html#Options gucke,
dann fügt -L den angegebenen Pfad lediglich zum Suchpfad des Linkers
hinzu. Sollte in deinem Fall also sogar überflüssig sein, da die IDE den
relativen Pfad der Object files mit angibt.
Ich würde mal versuchen, heraus zu finden, auf welchen absoluten Pfad
sich die relativen Pfade beziehen und ob das mit Deinen Erwartungen
passt. Vielleicht links Du da auch uralte Dateien zusammen.
Das Mapfile aus den Einstellungen "-Map mapping.map" wird direkt im
selben Pfad erstellt wie die CodeBlocks Projektdatei.
In diesem absoluten Pfad ist dann auch der obj/ Unterordner.
Also:
/home/spacy/blocks/mapping.map
/home/spacy/blocks/blocks.cbp
/home/spacy/blocks/obj/Debug/src/System/startup.o
Daher ist der LInkeraufruf eigentlich richtig.
Ja die Option -L müsste überflüssig sein.
Mit der Option findet er doppelt und ohne die Funktion garnichts.
Darauf kann ich mir echt kein Reim machen.
Wollte das Projekt jetzt mal von makefile + kate umbauen zu einer IDE.
Vorher hats ja funktioniert.
Im Endeffekt gehts mir eigentlich nur um eine GDB GUI für meinen MIPS
Eulator mit GDB Server, die Standalone GUIs haben sich leider nicht als
brauchbar erwiesen.
Mw E. schrieb:> Daher ist der LInkeraufruf eigentlich richtig.
Sehe ich genau so. Vielleicht den Aufruf so direkt mal von der Shell aus
aufrufen? Ggf. mal ohne startup.o, dann sollte doch eigentlich main()
als undefined symbol aufgeführt werden. Vielleicht bringt das weitere
Erkenntnisse.
> Im Endeffekt gehts mir eigentlich nur um eine GDB GUI für meinen MIPS> Eulator mit GDB Server, die Standalone GUIs haben sich leider nicht als> brauchbar erwiesen.
Ich habe dass hier als sehenswerten Tipp bekommen:
https://www.youtube.com/watch?v=-n9Fkq1e6sg&index=40&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH
Den Link merk ich mir mal vor.
Selber in der Konsole aufrufen sorgt für den gleichen Fehler, natürlich
vom richtigen Pfad aus aufgerufen.
Die startup.o rausgenommen, selber Fehler, keine undefined reference
Fehler.
So jetzt nehme ich mal Datei für Datei raus um zu gucken wos knallt.
Einmal in Endlosschleife bitte:
https://www.youtube.com/watch?v=2YQGpD6aMHc
Absoluter Pfad im Linkerscript
UND ICH DACHT DAS HÄTTE ICH SCHONMAL GEFIXT
dadurch, dass der Codeblocks die o Files in ein Extraordner packt, kann
er das ja nicht mehr finden...
Danke für deine Hilfe!
Mw E. schrieb:> Wollte das Projekt jetzt mal von makefile + kate umbauen zu einer IDE.
hast zwar den Fehler gefunden, aber trotzdem noch ein Hinweis:
du kannst Codeblocks auch deinen makefile geben,
damit bleibt dein Project weiterhin übertragbar auf andere Compiler/IDEs
Thread beobachten
Seitenaufteilung abschalten