Des problèmes avec mingw, encore et toujours. :/

[Lolilolight]

J'ai pensé à installer le compilateur tdm 32 bits, ça compilait bien il y a 2 jours, et puis, je me retrouve avec cette fichue erreur qui ne sort de je ne sais pas d'ou :

obj\Debug\main.o:c:\tdm-gcc-32\lib\gcc\mingw32\4.8.1\include\c++\iostream|74|first defined here|

Hors que je n'ai pas touché à mon code.

PS : je devrais peut être changer de compilateur, et en prendre un qui marche une bonne fois pour toutes.

[Lolilolight]

Enfin soit voilà de quoi je voulais parler quand je citais les problèmes avec les nouveaux compilateur et le c++11. (Et je ne le fait pas pour manquer de crédulité)

Je pense que je vais repartir sur un compilateur mingw basique avec du dwarf2, je vois que apparemment c'est encore en phase expérimentale les nouveaux compilateurs avec le nouveau standard c++11.

 

[Laurent]

A mon avis t'as tout mélangé à force d'installer plein d'environnements différents, c'est pour ça que plus rien ne marche. Moi à ta place je virerais tout et je referais tout propre.

Quant à l'erreur "first defined here", il y a d'autres lignes d'erreur avant et après. Tout seul ça ne veut rien dire.

[Lolilolight]

Oui j'ai dû désinstallé et réinstallé différentes versions de mingw parce que j'arrivais pas à en trouver une qui marchait et qui me convenait.

J'ai aussi pensé au fait que il a du me laisser d'anciens fichiers.

J'ai essayer de désinstaller et réinstallé tdm-gcc 32 bits mais ça me retape la même erreur je crois que je vais carrément désinstaller le 64 et la 32 bits, faire un gros nettoyage et essayer de réinstaller la 32 bits, on verra ce que ça donnera.

[Lolilolight]

J'ai essayer de supprimer et de réinstallé mais ça ne résous pas le problème. :/

Je sens que je vais devoir changer de compilateur et me retaper la compilation de SFML et SFGL.

[Lolilolight]

Bon on dirait que ce n'est que lorsque je link ma librairie qu'il me met cette erreur, j'utilise en effet iostream dans ma librairie, quand je compile ma librairie pas de problème mais quand j'utilise ma librairie dans un autre projet, il me met cette erreur.

obj\Debug\main.o:c:\tdm-gcc-32\lib\gcc\mingw32\4.8.1\include\c++\iostream|74|first defined here|

Mmmmmm....., je sens que code::blocks m'a encore fait une bourde avec les fichiers .o.

[Lolilolight]

J'ai essayer de recréer le projet avec code::blocks mais ça ne résous pas le problème non plus. :

Je n'ai plus qu'une solution alors c'est revenir à une version plus ancienne de mingw et tout recompiler.

[Lolilolight]

Houlalalala il y a un gros problème :

J'ai supprimer tout les dossiers de tdm-gcc, j'ai, installé le dossier de MinGW.

J'ai tout recompilé et même erreur :

obj\Debug\main.o:c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\iostream|74|first defined here|

Le plus bizarre c'est que ce fichier a été supprimé donc je ne comprends comment code::blocks arrive encore à me le retrouver et à me renvoyer cette erreur.

PS : Code blocks génère un makefile

Bref je crois que je vais essayer de compiler mon projet avec CMake, ça doit surement être le makefile de code::blocks qui merde. :/ (A force d'avoir désinstallé et réinstaller des compilateurs.)

[Lolilolight]

En compilant mon projet avec CMake j'ai réussi à tirer plus d'information sur l'erreur :

http://www.hostingpics.net/viewer.php?id=611823erreur.jpg

[Lolilolight]

Bon j'ai réduit le code source petit à petit et je me suis rendu compte finalement que j'ai des problèmes avec la stl :

#0 ??   _M_lower_bound (this=<optimized out>, __k=..., __y=<optimized out>, __x=0x3f800000) (c:/mingw/lib/gcc/mingw32/4.8.1/include/c++/bits/stl_tree.h:1154)
#1 ??   find (__k=..., this=0x28fc58) (c:/mingw/lib/gcc/mingw32/4.8.1/include/c++/bits/stl_tree.h:1802)
#2 ??   find (__x=..., this=0x28fc58) (c:/mingw/lib/gcc/mingw32/4.8.1/include/c++/bits/stl_map.h:836)
#3 ??   sfgl::ResourceManager<sf::Texture>::getIdByAlias (this=this@entry=0x28fc40, alias=...) (C:/SFGL/include/SFGL/Core/../../../include/SFGL/Core/resourceManager.h:85)
#4 0040E918     sfgl::ResourceManager<sf::Texture>::getResourceByAlias(this=this@entry=0x28fc40, alias=...) (C:/SFGL/include/SFGL/Core/../../../include/SFGL/Core/resourceManager.h:119)
#5 00410848     render(this=0x28fbf4) (D:/Projets/Projets-c++/TestSFGL/myApplication.h:31)
#6 ??   exec (this=0x28fbf4) (D:/Projets/Projets-c++/TestSFGL/myApplication.h:77)
#7 ??   _fu49___ZNSs4_Rep20_S_empty_rep_storageE () (D:\Projets\Projets-c++\TestSFGL\main.cpp:12)
 

Voici la ligne de code qui fait tout crasher :

std::map<std::string, int>::const_iterator it = mAliasMap.find(alias);
 

Je n'avais jamais utiliser les const_iterator..., je vais essayer avec un itérateur simple pour voir...

[Lolilolight]

Ok bon apparemment l'erreur vient d'ici :

template <typename R>
void Application::addResourceManager(ResourceManager<R>& rmi, std::string name) {
    std::map<std::string, ResourceManager<void*>&>::iterator it = resourceManagers.find(name);
    if (it != resourceManagers.end())
        throw Erreur (11, "Resource manager already added!", 0);
    resourceManagers.insert(std::pair<std::string, ResourceManager<void*>&>(name, rmi));
}
template <typename R>
ResourceManager<R>& Application::resourceManager(std::string name) {
    typename std::map<std::string, ResourceManager<void*>&>::iterator it = resourceManagers.find(name);
    if (it == resourceManagers.end())
        throw Erreur (12, "Resource manager not found!", 0);
    return static_cast<ResourceManager<R>&>(it->second);
}
 

La STL n'aime pas qu'on utilise un pointeur sur void (ou bien un template, alors là ça ne compile même pas), dans ses conteneurs.

[Lolilolight]

Ha j'ai trouvé c'est parce que je référençais un texturemanager qui n'existait plus et pour le deuxième problème, mmm, je pense que le problème vient d'une inclusion cyclique. (car application inclus map et dans application j'inclus map aussi)

[Laurent]

Tu sais tu n'es pas obligé de venir écrire un post dès que tu fais quelque chose. Je paye cher le Mo de base de données

[Lolilolight]

Ok, pas de problèmes, de toute façon j'ai résolu mon problème.