Impossible d'executer un programme

[compositeur]

Bonjour à tous, j'ai parcouru le forum sans trouver de réponse à mon problème, je décide donc de créer un nouveau topic.
J'ai découvert la sfml il y a un ou deux ans déjà, et tout marchais bien. Pendant un moment, je me suis arrêté d'utiliser la SFML (manque de temps pour programmer, en fait), et j'ai profité des vacances pour m'y remettre. Seulement voila, plus aucun de mes programmes créer avec la sfml ne fonctionnent. J'ai essayer de réinstaller la bibliothèque mais rien n'a changé.
Je compile sous windows, avec la sfml 1.6. A priori, la seule qui aie changée est le fait que je suis passé à c++0x. En copiant collant un programme tout bête qui est censé simplement ouvrir une fenêtre, (

#include <SFML/Window.hpp>


int main()
{
    // Create the main window
    sf::Window App(sf::VideoMode(800, 600, 32), "SFML Window");

    // Start main loop
    bool Running = true;
    while (Running)
    {
        App.Display();
    }

    return EXIT_SUCCESS;
}
 

), mon code compile correctement. Simplement, à l'execution, aucune fenêtre ne s'ouvre, uniquement la console, et une ou deux secondes après, j'ai une erreur qui me dit que le programme a cessé de fonctionner (Même topo pour mes anciens projets SFML). J'ai lancé le debuger pour trouver d'où venait l'erreur. Il me pointe sur cette ligne :

 sf::Window App(sf::VideoMode(800, 600, 32), "SFML Window");

en m’annonçant une segmentation fault.

Le problème vient-il de c++0x ? Quelles sont les marches à suivre ?

[compositeur]

N'ayant toujours pas de solution, je re-up le topic...

[Laurent]

Quelle est ta version de gcc ? Quelle est ta carte graphique ?

[compositeur]

gcc (GCC) 4.7.0 20120211 .

Ma carte graphique, c'est une ATI Radeon HD.
Mais je n'ai pas changé de carte graphique entre temps...

[Laurent]

Il faut que tu recompiles SFML, ta version de gcc n'est plus compatible avec celle qui a été utilisée pour compiler SFML 1.6 à l'époque.

[compositeur]

Je n'ai pas réussi à recompiler ;
En attendant, j'ai globalement résolu le problème, je compile avec l'option -std=c++98 .

[kamui]

Salut,
Tu n'as pas résolu ton problème tu l'a contourné

regardes ici et si tu as des difficultés n'hésite pas à ( chercher encore? ) demander, ce sera mieux que de te coltiner une norme aussi vieille

[Laurent]

Tu n'as pas résolu ton problème tu l'a contourné

En fait c'est pas mal comme solution pour ceux qui n'utilisent pas C++11. Je pensais que gcc 4.7 sous Windows était complètement incompatible (binairement) avec les versions antérieures ; s'il suffit de se mettre en mode C++98 pour que ça fonctionne, c'est déjà une bonne nouvelle et surtout ça m'aide beaucoup.

[kamui]

CMake, même pour la 1.6 par exemple, ne permet pas de regénérer les libs SFML correctement pour la 4.7 de gcc ? Je sais que j'avais eu des problèmes avec la 1.6 et gcc 4.7, mais je suis passé à la 2 au lieu de tenter CMake...


En tout cas, même si c'est une bonne nouvelle, ça reste une solution de contournement ! ( rroooooh le chieeeuur  )

[Laurent]

Si bien sûr, à partir du moment où tu recompiles SFML avec le compilo que tu vas utiliser pour ton projet, ça va forcément marcher. Moi ce qui me préoccupe c'est de savoir quelles version de gcc je vais supporter pour la release (ie. je vais précompiler SFML pour quelles versions). Du coup ce genre d'info ça m'aide pas mal

[kamui]

pourquoi ne pas tout simplement avoir fait une libraire avec une compatibilité descendante infaillible dès la 1.0 ? C'est tellement simple 

Sinon pour la version de gcc, je le dis même si tu dois être encore plus au courant que moi, mais la dernière version téléchargeable de CodeBlocks (qui doit être l'IDE le plus utilisé par nous les débutants) propose gcc-4.6.2 je crois, qui permet d'utiliser une grosse partie (suffisante pour débuter et un peu plus) des nouvelles fonctionnalités de la dernière norme (je crois que la 4.7 ne rajoute que les mots-clés final et override (surcharge explicite) et les constructeurs délégués, y'a  surement d'autres trucs mais bon, c'est pas primordial pour tout le monde je penses) ou pas, et j'ai pas constaté autant de problèmes qu'avec 4.7, puisque j'ai du recompiler que les lib statiques pour la 2.0RC, à part ça ça fonctionnait niquel avec la 1.6 (et j'ai pas testé avec de plus vieilles) donc pour ce qui est de la rétrocompatibilité avec cette version t'aurais pas trop à te torturer le ciboulot  .

En espérant que ça puisse t'aider

[Laurent]

pourquoi ne pas tout simplement avoir fait une libraire avec une compatibilité descendante infaillible dès la 1.0 ? C'est tellement simple

Là on parle de la compatibilité entre les versions de gcc, pas de SFML

En fait ce qui pose problème c'est qu'une même version de gcc peut être compilée avec différentes options (modèle de threading, modèle d'exceptions, bibliothèque standard, ...), qui rendent ces versions incompatibles entre elles. Là on parle de compatibilité binaire, pas de ce que le compilo implémente du langage.

[kamui]

pourquoi ne pas tout simplement avoir fait une libraire avec une compatibilité descendante infaillible dès la 1.0 ? C'est tellement simple

Là on parle de la compatibilité entre les versions de gcc, pas de SFML

Ah oui au temps pour moi.

En fait ce qui pose problème c'est qu'une même version de gcc peut être compilée avec différentes options (modèle de threading, modèle d'exceptions, bibliothèque standard, ...), qui rendent ces versions incompatibles entre elles. Là on parle de compatibilité binaire, pas de ce que le compilo implémente du langage.

Euhh... en fait je croyais comprendre quelque chose à notre conversation mais je me suis peut-être un peu enflammé  :
- modèle de threading, modèle d'exceptions, bibliothèque standard, ... : tu veux dire qu'on peut recompiler gcc à sa sauce et qu'en le faisant on obtiens des versions qui sont incapables de compiler le même projet ?
- ce que le compilo implémente ça a pas un impact sur les binaires et donc sur la compatibilité binaire ?


Mes question ont l'air bêtes je crois que j'ai rien compris, donc on va faire plus simple :
C'est quoi la compatibilité binaire ?

[Laurent]

Euhh... en fait je croyais comprendre quelque chose à notre conversation mais je me suis peut-être un peu enflammé

C'est bien ce que je pensais

- modèle de threading, modèle d'exceptions, bibliothèque standard, ... : tu veux dire qu'on peut recompiler gcc à sa sauce

Il n'y a pas vraiment de compilation "officielle" de gcc sous Windows, du coup oui, chacun fait à sa sauce et compile même potentiellement plusieurs variantes directement.
L'exemple le plus parlant est la page des versions de gcc compilées par TDM : tu as déjà trois variantes pour chaque version de gcc : SJLJ 32 bits, DW2 32 bits, SJLJ 64 bits. (SJLJ et DW2 sont des modèles d'exception). Ensuite à partir de gcc 4.7 tu trouves aussi des versions dont le modèle de threading est pthread, alors que pour les versions précédentes c'était plutôt win32. En fait sous Windows il commence à y avoir un nombre exponentiel de variantes de gcc incompatibles entre elles.

et qu'en le faisant on obtiens des versions qui sont incapables de compiler le même projet ?

Non. L'incompatibilité apparaît si tu essayes de mélanger un binaire compilé avec une version X (par exemple les bibliothèques de SFML) dans du code compilé avec une version Y (par exemple ton projet qui utilise SFML).

- ce que le compilo implémente ça a pas un impact sur les binaires et donc sur la compatibilité binaire ?

Pas tellement, ou alors indirectement. Par exemple si tu compiles en mode C++11, tu vas implicitement utiliser la version 2011 de la DLL de la bibliothèque standard, alors que si tu compiles en mode C++98 tu vas utiliser la version 1998, et visiblement ces deux DLLs ne sont pas compatibles.

C'est quoi la compatibilité binaire ?

Pour ce qui est de la définition globale : quand tu peux remplacer une bibliothèque par une autre version sans recompiler le programme qui l'utilise, et que ce programme continue toujours de fonctionner, alors ces deux versions de la bibliothèque sont dites compatibles binairement -- tu peux interchanger les binaires sans conséquence. Typiquement, une version qui ne fait que des corrections de bugs internes sera compatible binairement avec sa version précédente.

Retournons maintenant à notre cas. Quand gcc compile un programme, il y place certains appels de fonctions propres à son environnement : typiquement tout ce qui vient de la bibliothèque standard, ce qui sert à gérer les exceptions et les threads.
Lorsque tu essaye de compiler un programme avec une version de gcc différente de celle qui a été utilisée pour compiler SFML, il peut se passer deux choses :
- certaines fonctions appelées par les DLLs de SFML ne sont pas retrouvées dans les bibliothèques de ton gcc gcc : tu as une erreur d'édition de liens sur des noms de fonctions sortis de nulle part (car internes à gcc)
- certaines fonctions sont là mais prennent des paramètres différents dans ta version de gcc (par exemple) : ça crashe à l'exécution

[kamui]

Merci pour cette explication, je me coucherai moins con ce soir