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
