undefined reference problem



  • Hey,

    ich nutze fuer mein Projekt die autotools um die makefiles zu erzeugen die Projekt struktur sieht wie folgt aus:

    main
     - src
      --math
      --renderer
      --...
     - include
      --math
      --...
    

    Wenn ich jetzt im renderer verzeichnis einen friend operator aus dem math Verzeichnis aufrufen moechte, krieg ich eine undefined reference. Wenn ich aber auf die Klassen methoden oder parameter zugreife funktionert das. Wo ist mein Problem. Hier ist das makefile.am

    bin_PROGRAMS=collision
    
    collision_SOURCES = math/point3.cpp math/vector3.cpp math/mathobject.cpp math/collision.cpp\
    math/sphere.cpp  math/rectangle.cpp utils/color.cpp renderer/renderobject.cpp\
    renderer/gameobject.cpp renderer/ball.cpp renderer/panel.cpp window/window.cpp\
    game.cpp main.cpp
    
    collision_LDFLAGS = -L/usr/X11R6/lib -lGL -lGLU -lglut -lXi -lXmu -lXext -lX11 -lm -lcwiid -lglpng \
    	           -L~/src/sfml/lib -lsfml-graphics -lsfml-window -lsfml-system
    
    collision_CPPFLAGS = -I/usr/local/src/boost-trunk -I/usr/local/include -I../include
    

    hier ist die linker Ausgabe:

    g++  -g -O2 -L/usr/X11R6/lib -lGL -lGLU -lglut -lXi -lXmu -lXext -lX11 -lm -lcwiid -lglpng -L/home/moe/src/sfml/lib -lsfml-graphics -lsfml-window -lsfml-system  -o collision collision-point3.o collision-vector3.o collision-mathobject.o collision-collision.o collision-sphere.o collision-rectangle.o collision-color.o collision-renderobject.o collision-gameobject.o collision-ball.o collision-panel.o collision-window.o collision-game.o collision-main.o  -lcwiid 
    collision-ball.o: In function `engine::Ball::move()':
    /trunk/engine/src/renderer/ball.cpp:78: undefined reference to `engine::operator+(engine::Point3 const&, engine::Vector3 const&)'
    


  • in welcher source datei hast du den operator definiert? bist du sicher, dass der operator die richtige signatur (addition von punkt und vektor) hat?

    in manchen situationen ist die reihenfolge der parameter des gcc wichtig. vor allem sollte man sehen, dass die ganzen libs erst hinter allen source dateien stehen. ich denk aber, dass man das mit diesen wert- und nutzlosen autotools nicht hinbekommt.
    solange du kein feature der autotools brauchst, schreib lieber selbst ein makefile. das ist dann viel einfacher und funktioniert genauso wenn nicht sogar besser.
    bei sehr vielen paketen macht das configure mehr probleme als der source code. und es dauert oft länger, das configure abzuarbeiten, als den code zu compilieren. die autotools sind einfach nur mist.



  • besserwisser schrieb:

    in manchen situationen ist die reihenfolge der parameter des gcc wichtig. vor allem sollte man sehen, dass die ganzen libs erst hinter allen source dateien stehen. ich denk aber, dass man das mit diesen wert- und nutzlosen autotools nicht hinbekommt.

    naja da er bei kompilieren den operator ja findet sollte er ja auch definiert sein, Ausserdem hat er ja mit nem alten makefile funktioniert.

    besserwisser schrieb:

    solange du kein feature der autotools brauchst, schreib lieber selbst ein makefile.

    ich will meinen code aber auf mehreren plattformen zum compilieren bringen und deswegen sind die autotools schon sinvoll.

    gruss maurice



  • das heißt nur, dass er die deklaration findet. beim linken sucht er aber nach der definition.
    schau einfach nach, wie die ausführbare datei im alten makefile gelinkt wird und suche nach unterschieden zur neuen methode.



  • hab den fehler gefunden hatte die operatoren nicht im namspace und deswegen wurden sie nicht gefunden.

    gruss maurice


Anmelden zum Antworten