IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Problème avec mingw32-make multijob (make -jX)


Sujet :

C++

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 28
    Points : 17
    Points
    17
    Par défaut Problème avec mingw32-make multijob (make -jX)
    Bonsoir tout le monde,

    Je me pose une petite question toute bête. Je suis retourné sous Windows pour faire quelques tests après avoir mis à jour mingw32 et Qt.

    Conclusion, je ne sais pas pour quelle raison, mais lorsque j'execute un mingw32-make -j9, le -j9 n'est pas pris en compte. Le gestionnaire de tâche montre clairement que seul un processeur est utilisé...

    Du coup, j'ai tenté de faire un tour sous MSYS et le problème est différent. un make -j9 lance bel et bien la compilation à 100% du processeur, mais pour une raison qui m'échappe, il bloque très souvent lors de la compilation...

    Par bloquer, j'entends par là que la compilation n'avance plus même si le processeur reste occupé...
    Autre info, la compilation reste dans cet état plus longtemps que le make sans option avant que je ne shoote les processus... C'est bel et bien la preuve que ça coince quelque part...

    Bref, je suis un peu déboussolé par ce comportement. Ca fonctionnait très bien auparavant, mais là je ne comprends plus rien. D'ailleurs, pour info, le make -j9 continue de bien fonctionner sous linux...

    Quelqu'un aurait-il une idée, une piste?

    D'avance merci.

    Guillaume

  2. #2
    Membre expérimenté Avatar de Firwen
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    472
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Juin 2009
    Messages : 472
    Points : 1 587
    Points
    1 587
    Par défaut
    le -j X n'est pas une instruction magique, elle se contente de séparer chaque tache différente de ton makefile sur un thread différent :

    Ce qui veut dire :
    - Si le makefile comporte des scripts graddy et que ce n'est pas parallèlisable : ça plante.

    - Si tu as moins de 9 taches, le -j 9 est totalement ineffectif.

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    En premier lieu, merci de prendre le temps de me lire et de me répondre.

    Citation Envoyé par Firwen Voir le message
    le -j X n'est pas une instruction magique, elle se contente de séparer chaque tache différente de ton makefile sur un thread différent :

    Ce qui veut dire :
    - Si le makefile comporte des scripts graddy et que ce n'est pas parallèlisable : ça plante.
    Merci pour l'info : je l'ignorai.
    Je vais donc me documenter sur la question...

    Ceci dit, ce n'est pas le cas ici...

    Citation Envoyé par Firwen Voir le message
    - Si tu as moins de 9 taches, le -j 9 est totalement ineffectif.
    Le problème ne vient pas de là non plus... :-(

    Pour un peu plus d'info, je cherche à compiler Qt 4.7.0 et postgresql 8.4.5.
    Pour Qt, je l'avais déjà fait pour la 4.6.3 sans le moindre soucis et même chose pour PostgreSQL 8.3.8...

    Pour le compilateur, j'utilise celui que j'ai téléchargé sur le site de Nokia auquel j'ai rajouté quelques options (gettext, gmp, libgmp, libiconv, libmpc, libmpfr, libpthread, mpc, mpfr, pthread, zlib, openssl)

    La grosse différence qui me saute aux yeux entre cette fois-ci et l'autre fois, c'est que je n'ai pas pris le temps de recompiler minGW pour ma plateforme spécifiquement. C'est donc un target "i386-pc-mingw32". Est-ce que ça pourrait venir de là?

    Pour rappel, j'ai retenté l'ensemble sous Linux sans le moindre souci. Je pense donc que le souci vient du compilateur....

    Une petite idée?

    Guillaume, qui te remercie encore de ta réponse...

  4. #4
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 629
    Points : 30 692
    Points
    30 692
    Par défaut
    Salut,

    Il y a, en fait, plusieurs problèmes...

    Le premier est que la gestion des threads, des processus et de la mémoire est différente sous windows que sous linux.

    On arrive assez facilement à obtenir un processus zombie sous windows si, pour une raison ou une autre, il vient à y avoir une erreur mémoire trop importante

    Le deuxième est que MSYS n'est pas à proprement parler une machine virtuelle: on est beaucoup plus proche d'une "collection de mini programme" que l'on essaye de faire fonctionner de concert pour nous donner l'occasion de travailler "comme sous linux" que d'une distribution linux réelle fonctionnant sur une machine virtuelle (faut il rappeler que MSYS est l'abréviation de Minimalist SYSTEM)

    Le troisième est que l'ensemble des outils fournis par MSYS en particulier (mais peut être aussi ta version de make!!!) est effectivement compilé sous la forme d'une application 32 bits, ce qui oblige, si tu dispose d'une version 64 bits de windows, à fonctionner dans un mode de compatibilité, avec tous les problèmes que cela peut occasionner, entre autres, en terme de disponibilité de mémoire.

    Enfin, il faut savoir que, même sous linux, on conseille généralement de ne pas essayer de lancer plus de (nombre de coeur / processeurs) + 1 processus parallèles, histoire, justement, d'éviter que les différents processus n'en viennent à empiéter sur la mémoire les uns des autres.

    En outre, si tu utilise une version 64bits de Gcc et de binutils, il faut veiller à ce que binutils ait été effectivement compilé avec une version de Gcc capable de fournir des exécutables 64bits.

    Cela n'a l'air de rien, mais, lorsque tu compile toi même ces différents outils, binutils (et ld en particulier ) est compilé une première fois avec un compilateur qui, classiquement, ne fournit que des exécutables 32bits.

    Tu te trouve donc avec une version 32bit de ld capable d'effectuer l'édition de liens d'applications 64 bits.

    Mais, cette version de ld subit exactement les restrictions propres aux applications 32bits, dont, principalement, la restriction à une utilisation de maximum 2Gb de mémoire.

    Si je t'en parle, c'est simplement par expérience: si tu ne dispose pas d'une version 64bits de ld, le processus "plantera" à un moment parce que ld ne pourra pas utiliser suffisamment de mémoire lors du processus de compilation de Qt.

    Si tu compile toi-même les différents outils, tu dois donc veiller à compiler deux fois binutils:
    • La première fois en début de processus, de manière à ce qu'il puisse gérer les fichiers objets 64 bits
    • La seconde fois en fin de processus (après avoir compilé gcc) afin que ce soit effectivement une application 64 bits
    Hope it helps

  5. #5
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 629
    Points : 30 692
    Points
    30 692
    Par défaut
    Ah, au fait...

    Il me semble que sous linux, tu peux écrire tout aussi ben -j9 (sans espaces) que -j 9 (avec un espace), mais qu'il n'y a qu'une seule écriture qui fonctionne effectivement sous windows...

    Hé oui, make est un portage d'application, et ce portage pose parfois problème

  6. #6
    Membre à l'essai
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Pour commencer, merci pour tout ce lot d'information fort utiles. Pour information, j'avais suivi votre tutoriel pour compiler MinGW et comme il est clair et suffisamment détaillé, ce fut un "jeu d'enfant". Je profite donc de ce post pour vous en remercier et vous encourager à continuer!

    Citation Envoyé par koala01 Voir le message
    Salut,

    Il y a, en fait, plusieurs problèmes...

    Le premier est que la gestion des threads, des processus et de la mémoire est différente sous windows que sous linux.
    Ca, je le savais, mais c'est toujours une bonne chose de le rappeler...

    Citation Envoyé par koala01 Voir le message
    On arrive assez facilement à obtenir un processus zombie sous windows si, pour une raison ou une autre, il vient à y avoir une erreur mémoire trop importante
    C'est fort dommage et même fort dommageable...

    Citation Envoyé par koala01 Voir le message
    Le deuxième est que MSYS n'est pas à proprement parler une machine virtuelle: on est beaucoup plus proche d'une "collection de mini programme" que l'on essaye de faire fonctionner de concert pour nous donner l'occasion de travailler "comme sous linux" que d'une distribution linux réelle fonctionnant sur une machine virtuelle (faut il rappeler que MSYS est l'abréviation de Minimalist SYSTEM)
    Pour le côté un peu plus machine virtuelle, il y a Cygwin, mais personnellement je préfère l'approche "collection de mini-programme". Je viens de dotnet et si le côté machine virtuelle possède quelques avantages indéniables, il possède aussi des inconvénients non négligeables (dépendance de la MV, perfs déplorables si l'on se met à ne pas utiliser les objets fournis, ...)

    Citation Envoyé par koala01 Voir le message
    Le troisième est que l'ensemble des outils fournis par MSYS en particulier (mais peut être aussi ta version de make!!!) est effectivement compilé sous la forme d'une application 32 bits, ce qui oblige, si tu dispose d'une version 64 bits de windows, à fonctionner dans un mode de compatibilité, avec tous les problèmes que cela peut occasionner, entre autres, en terme de disponibilité de mémoire.
    Tout cela est fort intéressant. Je compte à moyen terme passer au 64 bits : c'est donc encore un point qu'il faudra que je prévois avant de basculer...
    Cependant, pour l'instant je ne suis qu'en 32bits... C'est d'ailleurs pour cette raison que je n'avais pas recompiler minGW. Comme il ne s'agissait que d'un test pour le moment...

    Cependant, si je suis bien en 32, je dispose d'un processeur récent et peut-être y a-t-il un souci si l'un des jeux d'instructions type SSE et Cie n'est pas déclaré. Je vais donc refaire une compilation de minGW avant d'aller plus loin dans la réflexion...

    Citation Envoyé par koala01 Voir le message
    Enfin, il faut savoir que, même sous linux, on conseille généralement de ne pas essayer de lancer plus de (nombre de coeur / processeurs) + 1 processus parallèles, histoire, justement, d'éviter que les différents processus n'en viennent à empiéter sur la mémoire les uns des autres.
    Effectivement, c'est un point que je connaissais déjà, mais j'ai la chance de posséder un processeur 4 coeurs / 8 threads et par conséquent m'autorise cette option.
    D'ailleurs, c'est principalement la parallélisation de compilation qui a orienté mon choix de processeur...

    Citation Envoyé par koala01 Voir le message
    En outre, si tu utilise une version 64bits de Gcc et de binutils, il faut veiller à ce que binutils ait été effectivement compilé avec une version de Gcc capable de fournir des exécutables 64bits.

    Cela n'a l'air de rien, mais, lorsque tu compile toi même ces différents outils, binutils (et ld en particulier ) est compilé une première fois avec un compilateur qui, classiquement, ne fournit que des exécutables 32bits.

    Tu te trouve donc avec une version 32bit de ld capable d'effectuer l'édition de liens d'applications 64 bits.

    Mais, cette version de ld subit exactement les restrictions propres aux applications 32bits, dont, principalement, la restriction à une utilisation de maximum 2Gb de mémoire.

    Si je t'en parle, c'est simplement par expérience: si tu ne dispose pas d'une version 64bits de ld, le processus "plantera" à un moment parce que ld ne pourra pas utiliser suffisamment de mémoire lors du processus de compilation de Qt.

    Si tu compile toi-même les différents outils, tu dois donc veiller à compiler deux fois binutils:
    • La première fois en début de processus, de manière à ce qu'il puisse gérer les fichiers objets 64 bits
    • La seconde fois en fin de processus (après avoir compilé gcc) afin que ce soit effectivement une application 64 bits
    Hope it helps

    Comme je le disais un poil plus haut, je ne suis pas en 64 bits (sous Windows) pour le moment, mais je conserve ces informations précieusement de côté.

    Encore un grand merci pour toutes ces infos. Je reposterai lorsque j'aurai eu le temps de compiler minGW, histoire de dire si ça a changé ou non quelque chose.

    Guillaume

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Ah, au fait...

    Il me semble que sous linux, tu peux écrire tout aussi ben -j9 (sans espaces) que -j 9 (avec un espace), mais qu'il n'y a qu'une seule écriture qui fonctionne effectivement sous windows...

    Hé oui, make est un portage d'application, et ce portage pose parfois problème
    Pour make dans msys, ça ne pose pas de problème en tout cas.
    Pour mingw32-make, j'ai fait un rapide petit test et ça n'a absolument rien donné...

    Tant pis, et merci tout de même pour le tuyau

  8. #8
    Membre à l'essai
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Bon, je n'ai malheureusement pas le temps de pousser plus loin pour l'instant, mais ça n'est que partie remise.

    Pour l'instant, tout ce que je peux affirmer, c'est que le problème vient bel et bien du MinGW.

    En effet, j'ai retrouvé une de mes vieilles versions de MinGW avec le code source de mame. J'ai donc fait trois tests :
    - compilation de mame avec mon minGW actuel (celui téléchargé du site de Nokia) et pas de prise en compte du -j9
    - compilation de mame avec le minGW que l'on trouve sur developpez.com à la pages des binaires Qt (GCC 4.4.0 (32 bits)) ==> même problème
    - compilation avec ma "vieille" version de minGW (4.2.1) ==> aucun problème, compilation à 100% du processeur...

    Etant donné que seul mingw change dans ce cas, ça ne peut venir que de là. D'ailleurs, avant d'effectuer ces tests, j'ai désinstaller MSYS pour être sur à 100% de mon coup...

    @koala01, ça a fonctionné avec un "mingw32-make -j9" et non "-j 9"...

    Quoiqu'il en soit, je compte bien trouver la solution ces prochains jours et en faire profiter ceux que ça pourrait intéresser...

    à plus tard

    Guillaume

  9. #9
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 629
    Points : 30 692
    Points
    30 692
    Par défaut
    Tiens, je viens de jeter un oeil à un script de compilation de make sous windows, et je constate que la configuration se fait (pour ce script particulier) en passant le paramètre --disable-job-server, qui, selon l'aide du script de configuration "disalow recursive make communication duing make -jN".

    Cette option a-t-elle été passée pour la version de make dont tu dispose aurait-elle du l'être

    J'ouvre une voie de réflexion, à toi de faire le reste

  10. #10
    Membre à l'essai
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Tiens, je viens de jeter un oeil à un script de compilation de make sous windows, et je constate que la configuration se fait (pour ce script particulier) en passant le paramètre --disable-job-server, qui, selon l'aide du script de configuration "disalow recursive make communication duing make -jN".

    Cette option a-t-elle été passée pour la version de make dont tu dispose aurait-elle du l'être
    Effectivement, c'est une piste fort intéressante! Je me pencherai sur la question avec le plus vif intérêt.

    Cependant, j'ai une question qui peut sembler très bête... Je ne sais pas comment retrouver les options avec lesquelles a été compilé make. Autant pour gcc, on dispose de toutes les infos avec un "gcc -v", autant là je ne vois pas comment faire...

    Citation Envoyé par koala01 Voir le message
    J'ouvre une voie de réflexion, à toi de faire le reste
    C'est bel et bien mon intention. Il n'y a qu'en se prenant un peu la tête qu'on avance.
    Cependant, comme je l'avais précisé dans mon précédent post, j'ai d'autres petites choses à faire en priorité pour l'instant. Je pense que je pourrais me repencher sérieusement sur le sujet lundi.

    Quoiqu'il en soit, merci pour ton observation, elle me permettra très certainement d'avancer beaucoup plus vite.

    Guillaume

  11. #11
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 629
    Points : 30 692
    Points
    30 692
    Par défaut
    Citation Envoyé par Guillaume78fr Voir le message
    Effectivement, c'est une piste fort intéressante! Je me pencherai sur la question avec le plus vif intérêt.

    Cependant, j'ai une question qui peut sembler très bête... Je ne sais pas comment retrouver les options avec lesquelles a été compilé make. Autant pour gcc, on dispose de toutes les infos avec un "gcc -v", autant là je ne vois pas comment faire...
    Je n'en ai strictement aucune idée...

    Mais, ceci dit, make est encore le genre d'application qui se compile très rapidement.

    Tu peux donc être relativement sur des options que tu passerais toi-même lors de sa compilation

    Tu ferais un test avec, et un test sans cette option particulière, et tu aurais assez rapidement une réponse quant à l'intérêt / le besoin ou non de la passer
    C'est bel et bien mon intention. Il n'y a qu'en se prenant un peu la tête qu'on avance.
    Cependant, comme je l'avais précisé dans mon précédent post, j'ai d'autres petites choses à faire en priorité pour l'instant. Je pense que je pourrais me repencher sérieusement sur le sujet lundi.

    Quoiqu'il en soit, merci pour ton observation, elle me permettra très certainement d'avancer beaucoup plus vite.

    Guillaume
    Oh, tu sais, pour moi, ce n'est pas un problème

    Je me suis dit que l'information était peut être intéressante, je l'ai transmise... Le reste, "i don't care"

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Oh, tu sais, pour moi, ce n'est pas un problème

    Je me suis dit que l'information était peut être intéressante, je l'ai transmise... Le reste, "i don't care"
    Je m'en doute bien, mais je pense que je ne suis pas le seul à rencontrer le problème. Voilà pourquoi je voulais répondre au plus vite à mon problème (ce qui est raté, comme on a pu le voir).

    Mon plus gros problème pour l'instant est de pouvoir dégager assez de temps pour compiler MinGW et résoudre le problème proprement.

    Pour ceux que ça pourrait intéresser, j'ai une piste qui me semble prometteuse..
    A l'heure actuelle, je n'ai qu'une version de MinGW qui exécute l'option -jX de make : c'est 4.2.1 avec les options de compilation suivantes :

    Configured with: ../gcc-4.2.1/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --program-suffix=-sjlj --with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw --with-local-prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry --enable-sjlj-exceptions --enable-libstdcxx-debug --enable-cxx-flags=-fno-function-sections -fno-data-sections --enable-version-specific-runtime-libs --disable-bootstrap
    Thread model: win32
    gcc version 4.2.1-sjlj (mingw32 sjlj-unwind)

    Par rapport à mes autres versions, les grosses différences sont :
    --enable-sjlj-exceptions
    et surtout :
    --enable-threads

    Pour SJLJ, j'ai vu que dwarf2 avait "pris le relais" car SJLJ posait des problèmes de stabilité. Quant à --enable-threads, le nom me semble suffisamment évocateur...
    Voilou, si quelqu'un compile avant moi, n'hésitez pas à confirmer ou infirmer cette hypothèse. Autrement, je reviendrai plus tard (sans précision de date...) pour le faire moi-même.

    Guillaume

Discussions similaires

  1. problème avec make
    Par nina2007 dans le forum Applications et environnements graphiques
    Réponses: 2
    Dernier message: 06/10/2008, 14h53
  2. link sous Eclipse avec mingw32-make et DLL Visual
    Par eag35 dans le forum Autres éditeurs
    Réponses: 2
    Dernier message: 16/04/2007, 09h22
  3. Cyrus-IMAP: problème avec le make
    Par Zelltemplar dans le forum Mandriva / Mageia
    Réponses: 6
    Dernier message: 11/04/2007, 09h18
  4. Problème avec make menuconfig
    Par toffff dans le forum Debian
    Réponses: 1
    Dernier message: 13/03/2007, 18h54
  5. [C++] Problème avec la commande "make"
    Par quantik-revolution dans le forum Systèmes de compilation
    Réponses: 6
    Dernier message: 02/04/2006, 18h17

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo