Faire une compilation idéale de GCC pour Windows…

Citation:

---

Envoyé par minnesota

Code:

---

.../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:

---

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

---

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...

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 ;)).

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 :aie:

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... ;)

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 ?

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, on est d'accord :aie:

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 ?

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 ;)

Citation:

---

Envoyé par koala01

Maintenant, je n'ai peut etre pas encore compris ton besoin

---

Je sais pas :aie:

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 ;)

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...