18 janv. 2010

gcc sous Windows ? C'est possible, mais...

... c'est pas simple. A la lumière de ma propre expérience, voici quelques points noirs (parce que les points pas noir, ça n'aide pas vraiment à faire un choix, n'est-ce pas) sur les plateformes de développement Windows basées sur GCC.

Cygwin

Le tout intégré. Cygwin est un environnement qui émule vaguement le fonctionnement d'un Unix-like sous Windows. Le coeur de cygwin, c'est sa DLL cygwin.dll qui permet à une application d'utiliser un grand nombre de services POSIX sous Windows.

C'est une bonne chose, surtout pour le portage d'applications ou de librairies. Ca ne va pas toutefois sans problèmes.

Installation

Le système d'installation est lourd et peu pratique à utiliser. A l'heure des gestionnaires de packages tel synaptic (Ubuntu), le système de cygwin montre d'ennuyeuses limites : ainsi, la sélection des packages est peu claire. Difficile de voir aussi quelles vont être les dépendances d'un package. Encore plus difficile, comprendre quel package est installé dans l'environnement. De mes tests, il est carrément plus simple de générer un répertoire cygwin en installant tout sur une machine avec un bon débit en download et de copier le répertoire cygwin sur une autre machine que de tenter de réaliser la même installation sur deux machines différentes. C'est petit...

/bin/sh, ou la lenteur faite programme.

La version cygwin du shell (en fait bash) est d'un lenteur à faire peur. Un script un peu chargé (par exemple un script généré par les autotools GNU) peut mettre jusqu'à plusieurs minutes à s'exécuter là ou le même script nécessite quelques secondes sous Linux. Je ne comprends pas vraiment très bien les raisons de cette incroyable lenteur, mais elle est là. Et bien évidemment, si le script est sur un disque partagé, le résultat est encore pire...

Des soupçons sur la stabilité ?

Les binaires que j'ai générés (à partir d'une code source en C++) souffrent tous du même mal : lorsqu'une exception est générée, le dépilement ne se fait pas correctement et la fonction abort() est appelée dès qu'on quitte la fonction qui génère l'exception. Impossible de contrer le problème, et impossible d'en comprendre la source. Je soupçonne un problème dans la librairie de GCC fournie avec la distribution - mais ça peut être aussi un problème liés aux options de compilation utilisées.

Une documentation peu explicite...
#include <iostream>
int main() { std::cout << "test" << std::endl }

Ce code pourtant simple génère un warning au moment du link et le programme généré ne fonctionne carrément pas. C'est dommage, étant donné que cette option de compilation ésotérique est censée être activée par défaut sur cygwin. En cherchant bien, et malgré les informations données par GCC et l'aide en ligne de GCC, c'est l'option --enable-runtime-pseudo-relocs qu'il faut utiliser à l'étape du linkage.

Mingw

Mingw est le concurrent de cygwin. Enfin, pas vraiment puisqu'il résout un problème différent : la création d'applications standard Windows en utilisant le compilateur gcc (plutôt que le portage d'applications POSIX sur Windows).

Installation

L'installation de cygwin est complexe, mais au moins, tout est automatisé. En comparaison, l'installation de mingw est représentative de ce que j'appellerais "la volonté de faire compliqué". En fait, si on veut un système vaguement équivalent à cygwin, il faut installer mingw, puis msys, puis ceci, puis cela, ... Le tout en passant par des download et des lignes de commande. Rébarbatif. Surtout quand on sait que généralement, les outils dont un développeur a besoin changent peu. Incroyable que ni les gens de cygwin ni les gens de mingw n'aient pensé à créer une archive avec le système complet pré-installé, histoire de gagner du temps (c'est mon employeur qui serait heureux ; j'aurais gagné une bonne demi-journée de travail...)

/bin/sh... ok, on sait déjà.

Mais ça n'empêche pas de revenir dessus. Le bash de mingw est lent, bien qu'il semble un poil plus rapide que celui de cygwin. Il reste néanmoins trop lent. Est-il si incroyablement complexe que personne n'ai pris le temps de comprendre d'où venait cette lenteur ? Les commentaires sur Internet parlent de 3 à 10 fois plus lent. C'est un peu trop à mon goût.

"Faire semblant" et "faire semblant"

Cygwin fait semblant d'être un OS avec une couche POSIX et y réussit relativement bien. MSYS fait semblant d'être une couche POSIX et échoue lamentablement. Il fait un peu trop semblant en fait. Le résultat, c'est un système de fichier complètement incompréhensible (franchement, ls -l / ne renvoie aucun répertoire /usr, ce qui n'empêche pas de faire cd /usr - et de se retrouver dans /. Enfin, je crois. Enfin, je ne comprends rien.). Sans compter que le système de montage de partitions est obscure, que /home/$user ne pointe pas sur le répertoire de l'utilisateur mais sur un répertoire spécialement créé, etc. Agaçant au possible.

Conclusion

Ces deux produits sont matures techniquement, mais souffrent d'un certain nombre de défauts qui ne facilitent pas leur utilisation en entreprise. Et bien sûr, j'en ai besoin (sinon, est-ce que ça serait ne serait-ce qu'un peu drôle ? Je vous le demande...)

Commentaires

1. Le lundi, janvier 25 2010, 14:40 par 3DArchi

Salut
Je ne suis pas sûr d'avoir tout compris à ton problème. Personnellement, j'installe gcc/mingw avec les versions TDM qui ont l'avantage d'avoir des versions gcc plus récentes. Là j'ai un compilo qui fonctionne correctement et que j'utilise en ligne de commande ou avec un I.D.E (CodeBlock pour ne pas le nommer). Je n'ai pas vraiment eu de problème.

2. Le lundi, janvier 25 2010, 21:56 par cheap webdesign usa

Bel article ! merci pour les infos, bonne continuation !

3. Le mercredi, janvier 27 2010, 19:10 par Emmanuel Deloget

Salut

Je ne suis pas sûr d'avoir tout compris à ton problème. Personnellement, j'installe gcc/mingw avec les versions TDM qui ont l'avantage d'avoir des versions gcc plus récentes. Là j'ai un compilo qui fonctionne correctement et que j'utilise en ligne de commande ou avec un I.D.E (CodeBlock pour ne pas le nommer). Je n'ai pas vraiment eu de problème.

Je pourrais faire la même chose mais...

Mon problème en fait c'est que je n'utilise pas directement gcc (ou g++) pour compiler mon programme. Je ne passe pas que par 'make' non plus. Je passe par un environnement type linux ou je peux exécuter un shell de type /bin/sh (générallement bash) afin de pouvoir exécuter un script configure relativement complexe. J'ai besoin de cet environnement pour palier à différents problèmes de portabilité.

Si on enlève cette contrainte, il est évident que les deux environnements sont parfaitement utilisables (modulo le problème d'exception trouvé avec cygwin, qui mérite encore une analyse plus poussée).

4. Le vendredi, avril 9 2010, 15:24 par Pouet

Encore une fois, merci. J'ai parcouru pas mal de forums pour tenter de résoudre mon problème, je crois que t'y apparaissait souvent.. Merci pour ton aide :)

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet