[gelöst]SFML in Code::Blocks einbinden

PhysiJokes

Guten Tag liebe Community,
ich versuche schon seit längerer Zeit SFML in meine Code::Blocks IDE einzubinden.
Zu diesem Thema habe ich auch einiges gelesen, aber ich verstehe das einfach nicht.
Vor allem in welcher Reihenfolge man diese Ordner einbinden muss.
Ich hoffe ihr könnt mir ein Schnelltutorial zum Einbinden von dieser Bibliothek geben.
Vielleicht ist es wichtig: Ich verwende den Gcc compiler

Schon mal Danke im voraus

Techel

Einfach alle quelldateien von sfml in ein projekt tun und in eine statische Bibliothek kompilieren.

PhysiJokes

Ja schon aber ich hab gelesen das man die einzelnen libs in einer bestimmten Reihenfolge linken muss

HarteWare

Schon das hier mal gelesen?
http://www.sfml-dev.org/tutorials/2.3/start-cb.php

dd2y

Man muss die DLLs erzeugen oder downloaden, falls vorhanden, die Header ins Programm einbinden und dem Linker die Library bereitstellen.

PhysiJokes

Ok ich hab das nach dem Tutorial auf der website von SFML gemacht.
Allerdings bekomme ich beim Testprogram zu allem mit SFML die Fehlermeldung
"undefined reference to ..."

Bei den SFML examples bekomme ich ausgegeben das die datei
"libgcc_s_sjIj_64-1.dll" fehlt.

Ich hoffe ihr könnt mir helfen.

Wichtig:
Ich nutze SFML2.3 und Code::Blocks

Finnegan

PhysiJokes schrieb:

Ok ich hab das nach dem Tutorial auf der website von SFML gemacht.
Allerdings bekomme ich beim Testprogram zu allem mit SFML die Fehlermeldung
"undefined reference to ..."

To was? Das wäre hilfreich zu wissen, das könnte nämlich entweder ein Fehler in deinem Programm sein (z.B. Implementation/Definition einer Funktion fehlt,
bzw. eine .cpp-Datei ist nicht im Projekt eingebunden), oder eine von SFML benötigte Bibliothek wurde nicht gelinkt, oder es wurden fehlerhafte Compiler/Linker-Flags verwendet,
oder eine falsche Version der bereits kompilierten SFML-Bibliotheken wurde heruntergeladen.

PhysiJokes schrieb:

Bei den SFML examples bekomme ich ausgegeben das die datei
"libgcc_s_sjIj_64-1.dll" fehlt.

Diese Datei ist Teil der Compiler-Runtime und befindet sich üblicherweise im "bin"-Unterordner, dort wo GCC installiert wurde.
Dieser Ordner muss entweder im aktuellen PATH sein, oder du musst die Datei in den Ordner kopieren, wo sich auch die .exe-Dateien der Examples befinden.

Falls sich in deiner GCC-Installation keine solche Datei befindet, passen wahrscheinlich die heruntergeladene SFML-Version und dein GCC-Compiler nicht
zusammen. Deine SFML-Version wurde offenbar für ein GCC mit SJLJ-Exception Handling gebaut. Falls du z.B. eine GCC-Version mit SEH- oder DW2-Exception Handling verwendest,
wird das nicht funktionieren.

Finnegan

PhysiJokes

Ok erstmal danke für die Informationen .

@Finnegan Ich bekomme die Fehlermeldungen bei allem was mit "sf::" beginnt
Zum Beispiel:
" undefined reference to sf::String::String(char const*, std::locale const&)' " oder: " undefined reference tosf::VideoMode::VideoMode(unsigned int, unsigned int, unsigned int)' ".

Und hier noch der SFML Testcode der einen grünen Kreis anzeigen lassen sollte:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

Diese Datei ist Teil der Compiler-Runtime und befindet sich üblicherweise im "bin"-Unterordner, dort wo GCC installiert wurde.
Dieser Ordner muss entweder im aktuellen PATH sein, oder du musst die Datei in den Ordner kopieren, wo sich auch die .exe-Dateien der Examples befinden.

Es kann eigentlich nicht vom Compiler abhängen da die examples fertige .exe dateien sind oder verstehe ich da etwas Falsch?

Finnegan

PhysiJokes schrieb:

Ok erstmal danke für die Informationen .

@Finnegan Ich bekomme die Fehlermeldungen bei allem was mit "sf::" beginnt
Zum Beispiel:
" undefined reference to sf::String::String(char const*, std::locale const&)' " oder: " undefined reference tosf::VideoMode::VideoMode(unsigned int, unsigned int, unsigned int)' ".

Stell nochmal sicher, dass du die Bibliotheken in den Linker Settings in genau dieser Reihenfolge eingetragen hast:
`

sfml-graphics

sfml-window

sfml-system

und dass du nicht die statischen Versionen verwendest (z.B.sfml-graphics-s` ), da statisches Linken etwas komplizierter und damit fehleranfälliger ist (das kannst du immer noch machen, wenn alles läuft).

Ebenfalls sollte SFML_STATIC unter #defines NICHT eingetragen sein (rauslöschen, falls das der Fall ist).

Beim Ausführen müssen sich dann auch hier die sfml-DLL-Dateien entweder im PATH , oder im selben Ordner wie die erstellten .exe-Dateien befinden.

Falls das immer noch nicht weiterhilft, dann poste ruhig mal die gesamten Meldungen, die der Compiler ausspuckt - da kann man dann etwas mehr herauslesen (z.B. sowas wie "libsfml-graphics.a nicht gefunden", was die Probleme ebenfalls erklären würde).

PhysiJokes schrieb:

Diese Datei ist Teil der Compiler-Runtime und befindet sich üblicherweise im "bin"-Unterordner, dort wo GCC installiert wurde.
Dieser Ordner muss entweder im aktuellen PATH sein, oder du musst die Datei in den Ordner kopieren, wo sich auch die .exe-Dateien der Examples befinden.

Es kann eigentlich nicht vom Compiler abhängen da die examples fertige .exe dateien sind oder verstehe ich da etwas Falsch?

Wenn die Runtime beim Erstellen der .exe-Datei (oder einer verwendeten DLL-Datei) nicht statisch gelinkt wurde (für GCC/C++ mit den Kommandozeilen-Optionen -static-libgcc -static-libsdtc++ ), dann müssen die DLL-Dateien der Runtime auf jedem System vorhanden sein, auf denen das Programm ausgeführt werden soll (entweder im PATH oder im Ordner der .exe-Datei). Vielleicht ist dir bei einigen Programmen schonmal die Visual Studio-Runtime begegnet (msvcrXXX.dll, msvcpXXX.dll, etc.). Das ist im Prinzip dasselbe. Microsoft bietet dafür z.B. diese VC Runtime Redistributable-Pakete zur separaten Installation an. Bei Programmen, die mit GCC gebaut wurden, packt man die DLL-Dateien entweder dazu, oder bietet sie ebenfalls zum Download an.
Ich vermute mal, dass bei deiner SFML-Version davon ausgegangen wird, dass du die Dateien von deinem Compiler nimmst (falls die nicht irgendwo in der SFML-Installation versteckt sind).

Finnegan

PhysiJokes

Ok danke,
Bisher habe ich tatsächlich versucht das ganze Statisch zu linken und jetzt Dynamisch versucht. Da kamen dann andere Errors aber auch 19.
Und ja ich habe sie in der Reihenfolge:
sfml-graphics-d
sfml-window-d
sfml-system-d
(Das "-d" weil ich in Debug bin)

Hier alle meldungen:

||=== Build: Debug in SFML (compiler: GNU GCC Compiler) ===|
obj\Debug\main.o||In function main':| |5|undefined reference to_imp___ZN2sf6StringC1EPKcRKSt6locale'|

|5|undefined reference to `_imp___ZN2sf9VideoModeC1Ejjj'|

|5|undefined reference to `_imp___ZN2sf12RenderWindowC1ENS_9VideoModeERKNS_6StringEjRKNS_15ContextSettingsE'|

|6|undefined reference to `_imp___ZN2sf11CircleShapeC1Efj'|

|7|undefined reference to `_imp___ZN2sf5Color5GreenE'|

|7|undefined reference to `_imp___ZN2sf5Shape12setFillColorERKNS_5ColorE'|

|15|undefined reference to `_imp___ZN2sf6Window5closeEv'|

|12|undefined reference to `_imp___ZN2sf6Window9pollEventERNS_5EventE'|

|18|undefined reference to `_imp___ZN2sf5ColorC1Ehhhh'|

|18|undefined reference to `_imp___ZN2sf12RenderTarget5clearERKNS_5ColorE'|

|19|undefined reference to `_imp___ZN2sf12RenderStates7DefaultE'|

|19|undefined reference to `_imp___ZN2sf12RenderTarget4drawERKNS_8DrawableERKNS_12RenderStatesE'|

|20|undefined reference to `_imp___ZN2sf6Window7displayEv'|

|9|undefined reference to `_imp___ZNK2sf6Window6isOpenEv'|

|23|undefined reference to `_imp___ZN2sf12RenderWindowD1Ev'|

obj\Debug\main.o||In function `ZN2sf11CircleShapeD1Ev':|

|41|undefined reference to `_imp___ZTVN2sf11CircleShapeE'|

|41|undefined reference to `_imp___ZN2sf5ShapeD2Ev'|
||=== Build failed: 19 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

Finnegan

Ich hatte eigentlich gehofft, die Ausgabe sei etwas informativer.
Es fehlt z.B. die Kommandozeile, mit der der GCC-Compiler aufgerufen wurde.

Versuch mal, der IDE ein wenig mehr Auskunftsfreude beizubringen. Hier eine Anleitung:

http://en.sfml-dev.org/forums/index.php?topic=12552.0

... und poste dann nochmal den Output. Keine Garantie, dass ich dir dann weiterhelfen kann,
aber viellecht springt mir dann etwas offensichtliches ins Auge, habe einiges an Erfahrung mit kompilieren und Einbinden von Bibliotheken - wenn auch nicht mit SFML (bisher noch nicht verwendet),
das sind aber typische Probleme, die man immer wieder hat, wenn man Bibliotheken verwendet.

Eigentlich sollten die nicht gefundenen Symbole im sf::-Namespace in den zugehörigen Importbibliotheken ( libsfml-graphics-d.a , etc.) definiert sein und auf
die entsprechenden Funktionen in den DLL-Dateien verweisen. Keine Ahnung, weshalb er die nicht findet (kann viele Ursachen haben), daher hilft ein detaillierterer Build-Log eventuell weiter.

Gruss,
Finnegan

Erhard Henkes

Ist der Zusammenhang debug/release und 32/64 bit wirklich komplett passend? Probiere doch mal die Release- und die 32-bit-Version. Sollte eine Stufe einfacher sein.

PhysiJokes

Juhu es funktioniert ,
Vielen danke für eure Hilfe

Ich hab ein bisschen mit den Versionen experimentiert (Um genau zu sein 4 SFML Versionen und zwei Code::Blocks Versionen) und dabei habe ich im Kleingedruckten gelesen, dass die 64-bit Version von Code::Blocks zwar auf 64-bit Systemen
arbeitet, aber die mitgelieferte gnu gcc edition 32-bit ist. Somit brauchte ich nur die 32-bit Version von SFML herunterzuladen und Zack es funktionierte. Vielen vielen Dank für eure Hilfe.

Am Ende sind die Probleme immer unkomplizierter als man zuerst denkt .

Finnegan

PhysiJokes schrieb:

Am Ende sind die Probleme immer unkomplizierter als man zuerst denkt .

Das schwierige an deser Art von Problemen ist, dass sie 10000 verschiedene, allesamt simple Ursachen haben können. Glückwunsch

Übrigens, je nach GCC-Version reicht ein -m64 als Kommandozeilenparameter, um den Code für 64Bit zu bauen.
Ich hätte allerdings erwartet, dass GCC bzw. der Linker da eine etwas nachvollziehbarere Fehlermedung ausspuckt (inkompatible Architektur oder sowas).

Gruss,
Finnegan