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 :

Faire une compilation idéale de GCC pour Windows…


Sujet :

C++

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

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par minnesota Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    .../tdm64-gcc-4.8.1-3/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible .../tdm64-gcc-4.8.1-3/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a when searching for -lmsvcrt
    Du coup, je me demande si tdm64-gcc-4.8.1-3 est bien multilibs, parce que dans les faits il n'y a qu'un seul et unique fichier libmsvcrt.a dans tout le "package" et paradoxalement y'a bien un dossier "lib32"... Je cherche aussi un moyen efficace pour identifier de manière sure si une archive libxxxxxxxx.a est une lib pour produire du 64 bits ou du 32 bits...
    Il faut comprendre que ta chaine de compilation est en réalité composée de trois projets distincts :
    • Binutils, qui fournit essentiellement des outils pour manipuler les fichiers binaires et les fichier objets (dont ld qui est l'éditeur de liens)
    • Gcc qui fournit la collection de compilateurs susceptibles de compiler différents langages
    • la CRT qui fournit les bibliothèques utiles à l'édition de lien (et qui est fournie par le projet mingw-w64)
    Les compilateurs et l'éditeur de liens sont assez indépendant pour pouvoir générer du code 32bits et / ou 64 bits, à partir du moment où ils disposent de l'indispensable (fichiers d'en-tête adaptés à la version demandée pour le compilateur, bibliothèque compilée pour la bonne version pour l'éditeur de liens).

    Si l'éditeur de liens te dit qu'il ignore une bibliothèque parce qu'il a rencontrés "des pointeurs de type incompatible", c'est que la CRT n'est fournie que dans une seule version (par exemple 64 bits, alors que tu as spécifiquement demandé à ce que l'exécutable soit en version 32bits).

    Je ne me suis jamais intéressé à tdm en tant que tel, et je ne connais donc pas leur politique en ce qui concerne la gestion du multilib. Mais, selon ce que tu m'explique, j'aurais tendance à croire qu'ils fournissent des versions qui ne supportent pas le multilib. Du moins, pour la CRT.

    Tu as normalement un dossier x86_64-w64-mingw32 dans le dossier racine de MinGW.

    Tu y trouveras les fichiers de la CRT dans différents dossiers, dont un dossier lib, un éventuel dossier lib_32 et un éventuel dossier lib_64.

    Si tu ne trouves pas l'un des dossiers (le seul qui existera d'office étant le dossier lib), c'est que la CRT n'a pas été compilée en version multilib.

    Le problème, c'est que, si la CRT n'a pas été compilée en version multilib, il y a de fortes chances pour que les bibliothèques internes de Gcc (libstdc++, libquadmath et les autres) ne l'aient pas été non plus.

    Je te disais dans mon intervention précédente de vérifier si tu avais bien deux versions différentes pour les bibliothèques, statiques comme dynamiques. Généralement, les versions 64 bits sont de taille (largement) supérieure aux versions 32 bits.

    A titre de comparaison, les tailles pour les dlls de mon coté ressemblent à ceci (je rappelle que c'est une compilation perso ) et les tailles pour les libXX.a suivent une boucle à peu près similaire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    DLL                 | taille 32bits | taille 64bits
    libgcc_s_sjlj-1.dll |  470 ko       |  533 Ko
    libgfortran-3.dll   | 4686 Ko       | 6675 Ko
    libgomp-1.dll       |  324 Ko       |  407 Ko
    libquadmath-0.dll   |  878 Ko       | 1030 Ko
    libssp-0.dll        |  107 Ko       |  141 Ko
    libstdc++-6.dll     | 6533 Ko       | 8428 Ko
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #42
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    J'ai trouvé cette histoire bizarre, du coup je viens de refaire une installation, là je l'ai fait manuellement, et je retrouve bien les deux déclinaisons de la crt... et ça fonctionne... merci tdm, merci koala01...

    Pour en revenir à deux questions précédentes, pour savoir si un exe est 32 bits ou 64 bits, la commande "gnu file" est d'une aide certaine. Pour les libs, c'est la commande "objdump" avec le flag "-G" qui fournit de précieuses informations. Un coup de parseur sur tout ça et on devrait avoir quelque chose de robuste.

    Maintenant, est-ce que je peux espérer aboutir à une version personnalisée et multilib de gcc-mingw64 mais structurée d'une manière un peu plus simple, sur "une arborescence d'un seul niveau" : [bin, include, lib32, lib64..] ou est-ce utopique ? Pareil, au lieu de préciser "-m64" ou "-m32", utiliser un fichier de configuration ou une variable d'environnement ? En fait, ce que je voudrais, c'est faire un compilateur dont l'usage serait complètement transparent, qu'il soit en somme reconnu par un edi comme un mingw32 tout à fait classique. C'est possible ?

    Sinon c'est quoi ta position au sujet d'un compilateur multilib vs deux compilateurs différents ? Je demande ça, parce qu'à ce que j'ai lu, beaucoup préfèrent avoir deux versions dans deux dossiers séparés... ça semble plus commode à l'usage et surtout ils semblent avoir moins de déboire...

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

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    L'avantage d'avoir deux versions clairement séparée, que ce soit par leur nom ou par leur chemin d'accès, est qu'il "suffit" le plus souvent de définir une variable pour être sur que toute la chaine de compilation travaillera dans la version souhaitée.

    Deux exemple en vrac:
    Si tu as un dossier MingW-x86_64 qui contient toute l'arborescence des outils dédiés à la génération de binaires 64 bit un autre MinGW-x86 qui contient toute l'arborescence des outils dédiés à la génération de binaires 32 bits, il "suffit" de rajouter un des dossiers ou l'autre à ta variable PATH pour être sur de compiler soit en version 32bits soit en version 64bits.

    Tu peux aussi définir des valeurs pour --program-suffixe ou pour --program-prefix (je crois que ce sont ces options, du moins, à vérifier avec un configure --help) qui vont faire que les outils auront un nom différent. Il est quand même préférable d'avoir les deux versions dans des dossiers séparés (parce que je ne suis pas sur du tout des noms de dossiers qui seront générés pour l'installation des bibliothèques, bien qu'il soit possible de les définir également ) mais tu peux alors définir "en dur" les chemins d'accès vers les deux version (pour éviter le recours à un fichier batch qui t'oblige à passer d'une console à l'autre pour changer de compilateur) et te "contenter" d'une de définir une variable représentant le compilateur utilisé. Le nom de la variable choisie est généralement CC pour le compilateur C et CXX pour le compilateur C++.

    Cette solution est parfois la seule manière de faire pour arriver à compiler certaines bibliothèques / certains framework dans les deux versions (je pense essentiellement à Qt, mais je crois que c'est aussi le cas de boost), parce qu'il n'y a pas moyen de pré/suffixer le nom des bibliothèques qui sont compilées. Il faut donc veiller à ce que les deux versions soient physiquement séparées, sous peine d'avoir une dll ou une bibliothèque statique dont la version ne correspondrait pas aux autres.

    L'avantage d'un compilateur réellement multilib, c'est que quand un projet est "bien foutu", tu peux facilement décider de le compiler pour l'une ou pour l'autre architecture (voire meme pour les deux) sans avoir vraiment à te poser de question. C'est le cas de binutils, de Gcc et de mingw-w64, mais il faut avouer que ca semble rester l'exception malgré tout.

    En ce qui concerne les déboires, il est clair que plus un système est complexe, plus tu risques d'avoir quelques soucis. Un système composé de deux versions clairement distinctes, sans interférences entre les deux sera beaucoup plus simple -- et donc beaucoup plus facile à utiliser --qu'un système qui "entremêle" les deux versions (sans même compter les différents problèmes que j'ai cités qui peuvent appraitre au moment de la compilation de ta chaines d'outils ).
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #44
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Dans ce cas alors, pour la "prod" un package multitarget (c.-à-d. avec deux versions séparées). Et pour expérimenter, quand même, un package multilib. Je pense que le moment venu, je ne préfixerais rien... seuls le dossier racine et peut-être une note supplémentaire permettront d'identifier la chaine de compilation au premier abord... parce que les x86-64-w32-w64 me donnent le tournis

    En tout cas merci à toi, c'est déjà un peu plus clair et surtout ça me donne une ligne de conduite pour la suite des choses...

  5. #45
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    salut,

    Même si ça peut sembler prématuré au premier abord, les fichiers d'instructions pour compiler les bibliothèques, pour une raison de sécurité, il faut que je les "uploads" compressés et signés/chiffrés sur le serveur. Mais à l'importation, je ne sais pas s'il est préférable de les utiliser tels quels, à la volée, ou s'il est mieux de les décompresser préalablement dans leurs formes initiales.

    T'en penses quoi koala01 ?

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

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Il me semble qu'on vérifie généralement l'intégrité de l'archive complete avant extraction, si tel est le but de ta question

    Les différentes clés sont donc calculées sur l'archive complète, avant de faire quoi que ce soit d'autre. Simplement parce que, s'il y a un ver dans l'archive, une fois qu'il est sorti, c'est trop tard
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #47
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Ça, on est d'accord

    Bon je reformule. En fait, les archives je peux les lire telles quelles, du moins sans avoir besoin de les décompresser sur le disque, donc pour la suite, je sais pas s'il est préférable que je laisse comme ça, ou s'il faut que j'ajoute une étape supplémentaire, et donc enregistrer sur le disque la forme décompressée/déchiffrée des dits fichiers ?

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

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Sur ce coup, je ne peux que prendre exemple sur ce qui se fait déjà...

    Mais, si tu regardes les distro debian-like, le deb est en définitive l'archive, sauvegardé tel quel dans /var/cache/apt, et c'est ce deb qui est utilisé pour l'installation/ la réinstallation du paquet.

    Il me semble préférable de stocker l'archive en local, sous la forme d'une archive, afin de permettre leur manipulation plus aisée. Maintenant, je n'ai peut etre pas encore compris ton besoin et il n'est pas impossible que d'autres aient une optique différente
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  9. #49
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Maintenant, je n'ai peut etre pas encore compris ton besoin
    Je sais pas

    En fait, les archives sont téléchargées aux besoins et enregistrées dans un répertoire dédié, mais je me demandais juste s'il était préférable de travailler directement sur les archives ou sur leurs formes décompressées. Je vais rester sur le premier point, sauf si quelqu'un a une objection.

    Merci

  10. #50
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Salut tout le monde,

    Pour en revenir aux archives, j'utilise en "background" une compression/décompression xz, ça fonctionne merveilleusement bien.

    À l'heure actuelle, le projet est finalisé dans les 80%. Ma dernière intervention dessus date du 6 février et je compte le reprendre très prochainement, j'espère, vers mi-mars. Dans tous les cas, sachez qu'il n'est pas abandonné. Ainsi avant de vous quitter, je tenais à ce que vous soyez rassurés.

    Merci à toutes les personnes qui ont participé à ce fil, et un merci tout particulier à toi mon très cher koala01...

+ Répondre à la discussion
Cette discussion est résolue.
Page 3 sur 3 PremièrePremière 123

Discussions similaires

  1. champs de bits dans une structure - option de gcc pour bon fonctionnement
    Par matdakillah dans le forum RedHat / CentOS / Fedora
    Réponses: 1
    Dernier message: 08/10/2008, 13h44
  2. Cherche une version stable de Qt3 pour Windows
    Par manublain dans le forum PyQt
    Réponses: 4
    Dernier message: 09/08/2008, 11h22
  3. Faire une compilation maven avec une JDK 1.5
    Par ggalou08 dans le forum Maven
    Réponses: 5
    Dernier message: 07/04/2008, 16h51
  4. comment faire une compilation separée
    Par gipfel11 dans le forum C
    Réponses: 3
    Dernier message: 08/03/2008, 10h28
  5. ?Faire une petite appli/ C en API windows
    Par booraq dans le forum Windows
    Réponses: 2
    Dernier message: 09/12/2006, 12h04

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