STLport in Eclipse+CDT mit MinGW



  • Hi,

    ich arbeite auf Windows mit Eclipse+CDT und MinGW. Da std::wcout von libstdc++ nicht unterstützt wird, wollte ich stattdessen STLport verwenden.

    STLport habe ich erfolgreich kompiliert (mit “make -f gcc.mak all”) und den STLport-Include-Pfad in Eclipse hinzugefügt.

    Wenn ich versuche folgendes Programm versuche zu kompilieren

    #include <iostream>
    
    int main(void)
    {
       std::cout << "test";
       return 0;
    }
    

    bekomme ich folgende Compiler-Fehler

    [i][...][/i]/STLport-5.2.1/stlport/stl/_streambuf.h undefined reference to `_imp___ZN11stlpmtx_std8ios_base16_M_throw_failureEv'
    [i][...][/i]/STLport-5.2.1/stlport/stl/_streambuf.h undefined reference to `_imp___ZN11stlpmtx_std4coutE'
    

    Wäre für jede Hilfe dankbar.



  • Warum solche Verrenkungen STLport zusätzlich installieren?
    Der MinGW hat doch ein STL-Tool an Bord.

    Der aktuelle MinGW hat doch keine Probleme mit dem Quelltext.

    Hab Eclipse noch nicht getestet - kann mir das bei dir nur
    erklären, wenn du den MinGW unter Eclipse nicht richtig installiert
    hast.

    MfG f.-th.



  • f.-th. schrieb:

    Warum solche Verrenkungen STLport zusätzlich installieren?
    Der MinGW hat doch ein STL-Tool an Bord.

    Die Begründung dafür ist bereits in meinem Orginalposting zu finden:
    std::wcout wird vom MinGW-eigenen libstdc++ nicht unterstützt. Ich werde es allerdings u.U. verwenden wollen.

    Mein Codebeispiel kompiliert natürlich auch ohne STLport; sollte aber eben auch mit.



  • Lade dir doch MingW 4.3 runter, da ist alles dabei.



  • Hab mal ein wenig gesucht und gelesen.
    Die STL des MinGW, auch der neueren Versionen für Windows, kann kein

    STD::wcout
    

    unter Linux soll der entsprechende Compiler das aber können.

    Du schreibst du hast

    STLport habe ich erfolgreich kompiliert (mit “make -f gcc.mak all”)
    

    neuere Versionen des MinGW für Windows haben aber kein "make"
    mehr das heißt bei denen heute anders.
    Hast du unter Linux mit dem gcc kompiliert oder mit irgendeinem
    anderen Compiler unter Windows der das "make" noch hat?

    MfG f.-th.



  • std::wcout
    

    so soll das nicht nicht "STD::..." 😡



  • Danke für die Antwort f.-th.

    f.-th. schrieb:

    Hab mal ein wenig gesucht und gelesen.
    Die STL des MinGW, auch der neueren Versionen für Windows, kann kein

    STD::wcout
    

    unter Linux soll der entsprechende Compiler das aber können.

    Es gibt auf Sourceforge eine Alpha-Version [1], die es vielleicht kann (sieht jedenfalls so aus, wenn man sich die Header-Dateien anschaut), die bekomme ich aber nicht zum Laufen (ist halt noch Alpha, denk’ ich mal).

    f.-th. schrieb:

    Du schreibst du hast

    STLport habe ich erfolgreich kompiliert (mit make -f gcc.mak all)
    

    Stimmt, da habe ich mich unklar ausgedrückt. Das “MinGW-make” nennt sich mingw32-make.



  • Ich habe auf http://nuwen.net/mingw.html eine MinGW-Distribution (die außerdem bereits noch einige andere nützliche Komponenten enthält) mit dem GCC 4.3 (der auch std::wcout unterstützt) entdeckt.



  • Hier ein Link, der den gcc 4.3.2 MinGW-kompatibel anbietet:
    http://www.tdragon.net/recentgcc/

    Hab das mit Code::Blocks geprüft - hab 4 Versionen des MinGW auf der Platte -
    brauchte nur: "Settings" - "Compiler + Debugger Settings" - "Toolchain executables"
    klicken und da meinen Path anpassen.

    Ich denke, das sollte auch bei dir eine einfache Möglichkeit sein.

    Den Code

    #include <iostream>
    
    int main()
    {
    	std::wcout << "hello";
    }
    

    kann er compilieren.

    Gibt es eine brauchbare Anleitung für den gcc 4.3.x von der GNU-seite
    diesen unter Windows zum Laufen zu bringen? Hab das versucht, aber die
    Verzeichnisstruktur ist anders als bei den älteren MinGW. Oder hab ich
    einen anderen Link erwischt?

    Ach ja der Digital-Mars mit STLport übersetzt den Code auch.

    MfG f.-th.



  • Zu deiner ursprünglichen Frage, Eclipse+CDT mit MinGW 3.4.x:

    Hast du den STLport-include-Pfad so angelegt,
    das er zuerst auf die STLport-includes zugreift und
    dann erst auf die anderen, so hab ich es beim Digital-Mars,
    oder hast du den STLport-include-Pfad nur an die anderen
    Includes angehängt?
    Letzteres, sollte nicht funktionieren.

    Schreib mal was du noch erreicht hast.

    MfG f.-th.



  • f.-th. schrieb:

    Hast du den STLport-include-Pfad so angelegt,
    das er zuerst auf die STLport-includes zugreift und
    dann erst auf die anderen, so hab ich es beim Digital-Mars,
    oder hast du den STLport-include-Pfad nur an die anderen
    Includes angehängt?

    Der Include-Pfad für die STLport-Includes stand an erster Stelle. Ich könnte mir vorstellen, dass wichtige STLport-Libs nicht gefunden wurden, obwohl ich den Library-Pfad eigentlich auch gesetzt hatte.

    f.-th. schrieb:

    Gibt es eine brauchbare Anleitung für den gcc 4.3.x von der GNU-seite diesen unter Windows zum Laufen zu bringen? Hab das versucht, aber die
    Verzeichnisstruktur ist anders als bei den älteren MinGW. Oder hab ich
    einen anderen Link erwischt?

    Auf das Problem bin ich auch gestoßen. Eine brauchbare Anleitung hab ich aber auch nicht gefunden 😉 Den MinGW von http://nuwen.net/mingw.html hab ich aber mittlerweile installiert und der scheint zu laufen.

    Damit bin ich erstmal zufrieden. Danke für deine Antworten!



  • Es scheint so zu sein das der GNU GCC 4.3.x ein wenig strenger
    die Aufrufkonventionen handhabt als die älteren 3.y.z

    Den GNU 4.3.2 hab ich für kleine Programme nun unter dem SciTE am
    Laufen. Mit den "normalen", vorgegeben Einstellungen erstellt er
    nur die .o-Datei, erst nach dem Umstellen des Aufrufcommandos wird
    eine .exe erstellt. Den Pfad hab ich auch noch vor dem Aufruf des
    SciTE angepasst.

    also in den "cpp.properties"

    cc=g++ $(ccopts) -c $(FileNameExt) -o $(FileName).o
    

    zu

    cc=g++ $(ccopts) -o $(FileName) $(FileNameExt)
    

    ändern

    Mal sehen, vielleicht gibt es ja noch weitere Lösungen 😉

    MfG f.-th.


Log in to reply