Discussion :

[jblecanard]

Sympa ça risque de servir à pas mal de monde !

[koala01]

Notez que la compilation se passe sans problème avec le snaphsot 4.9.0 mais qu'elle échoue avec la release 4.8.1 lorsqu'on essaye de compiler objective C(++) à cause d'un problème connu.

Cela m'a forcé à rajouter la possibilité de patcher les sources, j'arrive tout doucement au bout de la mise en place du script, et le correctif sera commité dés que je serai sur d'avoir fixé cela correctement (mais en prévoyant que d'autres patches puissent être installés ).

En attendant, un feedback est le bienvenu

[minnesota]

Ben alors, personne n'a testé ??? camboui ???

Comme je l'ai dit et comme mon objectif initial c'est légèrement modifié, je peux pas trop me disperser... si ça peut aider je peux fournir le nécessaire pour importer localement msys, ou à koala01, la liste des packages à télécharger pour que tu puisses les intégrer à ton script ?

De mon côté, ça avance doucement... l'ébauche étant fonctionnelle, j'attaquerais prochainement la refonte et consolidation du moteur Sourceforge agrémenté de quelques fonctionnalités supplémentaires...

[koala01]

Ben alors, personne n'a testé ??? camboui ???

Comme je l'ai dit et comme mon objectif initial c'est légèrement modifié, je peux pas trop me disperser... si ça peut aider je peux fournir le nécessaire pour importer localement msys, ou à koala01, la liste des packages à télécharger pour que tu puisses les intégrer à ton script ?

On verra cela par la suite.

En l'état, le script manque cruellement d'interactivité, mais il est fonctionnel et permet de choisir:

• entre une compilation en une seule passe ou en deux
• entre une compilation uniquement 32 bits ou une compilation "full 64bits", avec support du multilib
• d'installer (ou non)
  
  • Gdb,
  • make (en fait mingw32-make, pour éviter les conflits ),
  • gettext,
  • iconv (qui est une dépendance de gettext),
  • openssl,
  • libXml2

Je prévois d'y rajouter icu (intéressant pour boost), mais à part cela, manque-t-il quelque chose?

De mon côté, ça avance doucement... l'ébauche étant fonctionnelle, j'attaquerais prochainement la refonte et consolidation du moteur Sourceforge agrémenté de quelques fonctionnalités supplémentaires...

Je suis pressé de voir cela

[minnesota]

Je prévois d'y rajouter icu (intéressant pour boost), mais à part cela, manque-t-il quelque chose?

À part les grosses Lib GUI, boost, dans les très utiles en plus d'icu je mettrai aussi freetype, pango (?) et cairo... pour le reste, c'est en fonction des demandes... de manière non thématique, sdl, ffmpeg (je l'ai déjà utilisé, mais je me rappelle plus si c'était précompilé ou pas)... pdcurs... curl... et j'en passe...

Je suis pressé de voir cela

ça mijote

[camboui]

Oui, oui, dès que j'ai cinq minutes (de motivation )

[minnesota]

Coucou tout le monde

Bon, j'ai pas eu trop d'occasions de me pencher sur notre sujet ces derniers jours, mais je me suis rattrapé un peu hier soir. Allez, c'est parti pour un petit topo.

Désormais, NTSourceForge est pleinement opérationnel bien que tous les tests ne soient pas encore validés. En l'état, après l'ébauche et sa refonte, je le maintiens quand même au stade de preview, car son interaction directe avec l'environnement parent a été totalement remaniée, du coup c'est moins dynamique, mais ça contribue à avoir quelque chose de plus robuste. Aussi, dans l'ébauche j'avais donné la possibilité à l'utilisateur de transmettre des paramètres à NTSourceForge, notamment de filtrages, mais j'ai aussi révisé ma position sur ce point, car si ça doit être fait, je pense qu'il est préférable que ça soit pris en charge par le script client et non NTSourceForge, ceci afin que ça reste flexible et fiable... NTSourceForge importe les informations depuis la plateforme SourceForge et délivre un rendu au format standard CSV, le script client sélectionne ce qu'il a besoin et décide quoi faire avec...

Bon, y'a encore des fonctions à ajouter, pas mal de systèmes de contrôle à implémenter, des choses à peaufiner, mais on avisera par la suite... Voilà, donc si tout va bien et qu'il y'a pas de contre temps, peut être un package démo avec la preview de NTSourceForge disponible en téléchargement d'ici la fin de la semaine prochaine... après en fonction des ressentis, on verra ce qui mérite d'être encore délégué à NTSourceForge ou pas...

Voilà, voilà...

[minnesota]

Salut

Bon et bien voilà, c'est fait, l'archive "preview" est fin prête. Alors une petite description rapide du package. En même temps, ce message vaut pour "readme".

Alors, dans l'archive, vous trouverez 3 fichiers (ntsourceforge.cmd, simple_test.cmd, links_list.txt) et 3 dossiers avec leurs utilitaires (gnu sed, gnu sort, curl et ntseterrorlevel).

Donc d'abord "NTSourceForge", c'est le script moteur, c'est lui qui délivre le rendu au format [CT]SV.
"Links_list.txt" contient une liste de quelques liens SourceForge qui seront utilisés pour vous donner les différents aperçus correspondants.
"Simple_test" est un script exemple qui utilise NTSourceForge, c'est le script démo. Il ne fait rien d'autre qu'enregistrer le rendu dans un fichier texte "record.txt", l'affiche avec "notepad", et attend la fermeture de ce dernier pour passer au prochain lien disponible dans "Links_list". Bien sûr, "Simple_test" peut être modifié librement, éventuellement, pour tester différentes combinaisons de la variable "fields_sequence". Il en va de même pour "Links_list" avec ses différents liens.

Pour des informations complémentaires, n'hésitez pas à lire les notes contenues dans ces différents fichiers.

Aussi, pendant le traitement, donc après avoir lancé "simple_test", il peut être utile d'avoir une vue sur le contenu de "Links_list", et voir en parallèle la page de chaque lien sur votre navigateur, ceci afin que vous puissiez comprendre la signification des différents champs paramétrables du rendu, car je n'ai pas encore documenté les différents types de données disponibles ou pris en charge, ils sont juste énumérés, d'autant plus que d'autres vont être ajouté dont le but est de rendre l'utilisation de NTSourceForge plus intuitive et par la même occasion simplifier le développement de scripts clients.

Par ailleurs, en ce qui concerne NTSourceForge, je me suis attelé à réduire au minimum les dépendances avec "cmd", ceci éventuellement, dans l'optique d'en faciliter le portage vers "sh" ou équivalent.

Enfin, comme je l'ai déjà dit, bien qu'en "preview", NTSourceForge est opérationnel, et vous pouvez d'ores et déjà l'essayer au travers de vos propres scripts clients. Trés vite, vous remarquerez qu'avec on peut faire bien plus que ce qu'il n'y parait au premier abord.

Ah, aussi j'ai laissé un fichier avec un nom provisoire "ntprogresscurl" dans l'archive, il fait parti de NTDownload. Ici, il n'est pas utile pour la démo et peut-être effacé si vous le souhaitez.
De même, il est fort probable que les outils GNU soient préfixés d'un "g" ou de "gnu" dans la version future, pour éviter tout risque de confusion avec d'autres outils génériques aux noms identiques. Enfin, notez que NTSourceForge est encore en phase de "preview", donc il est encore sujet à modification, en d'autres termes, la compatibilité future avec vos scripts client n'est pas garantie. Si vous avez des remarques, bien sûr, n'hésitez pas.

Merci.

************************************************************************
Dossier de téléchargement: http://www.mediafire.com/?4f8hl132f8zda

P.-S.:
Ne faites pas attention au compteur des downloads,
parfois, hors session, ils sont tous à 0... en se loguant on a toujours les bonnes valeurs...
Aussi, je vous ai mis directement le lien du dossier, ce sera plus simple pour les mises à jour...
************************************************************************

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
md5sum of package:
 
7a13fdf9b9240b25696bf204575a2cb7 *NTSourceforge_preview.zip
 
md5sum of content of package:
 
0905a1601170d1e68497544cb14fb654 *simple_test.cmd
fcfbe47b1712cab4dd9f30d81507c051 *NTSourceforge.cmd
e54fec5dddac98339c7329e7482bf550 *NTSetErrorlevel.cmd
30e5e1be245b13277b0b9f070e83ef9f *ntprogresscurl.exe
d8a135724e39259ca1bdee290e530e8d *links_list.txt
4de87d064877fa6726654f6812a719b0 *sort.exe
ee837cf3356f57e8771ea3de3fb658f2 *sed.exe
547c43567ab8c08eb30f6c6bacb479a3 *regex2.dll
d202baa425176287017ffe1fb5d1b77c *libintl3.dll
e0dc8c6bbc787b972a9a468648dbfd85 *libiconv2.dll
b313435659964a67592173ee846a34bc *curl.exe

[minnesota]

re,

voilà les nouvelles données prises en charge:
(celles qui sont barrées, je pense les supprimer à la prochaine réédition)

::.@Notes:
:: Available types of data for NTSourceforge output:
:: project_name, name,
:: type, downloadable, date, utc_date, utc_time, size,
:: sha1, md5,
:: path, url, full_path, mirrors,
:: directory_url, download_url, short_download_url, download_label,
:: downloads, downloads_count,
:: legacy_release_notes,
:: stag, staged, explicitly_staged,
:: exclude_reports, default,

Le test de récursivité (que le script client peut opérer sur NTSourceForge) est un peu lent à mon gout, je pense le faire prendre en charge directement par NTSourceForge. De même, j'envisage d'apposer des flags pour que seules les opérations nécessaires (en fonction du format de sortie demandé) soient réalisées. Après je laisse murir la chose, et je retourne à notre fabrique, peut-être même avant

[minnesota]

Re salut,

J'ai repris la fabrique tôt ce matin histoire de me remémorer où j'en étais pour pouvoir retravailler un peu dessus ce week-end, et j'ai rencontré un petit souci pour le moins bizarre.

En effet, si je fais un "mount" bidon avec "sh" genre "mount /c/ /pm" et qu’ ensuite je fais un "unmount" avec "umount /pm" j'ai droit à un, de mémoire, "usr/bin/umount line 75, rm command not found", un truc comme ça, alors que cette commande "remove" "rm" suit la commande "copy" "cp" qui est bien entendu dans le même dossier "msys\bin" et qui ne pose pas de problème. Aussi, si je fais suivre la commande "rm" de la même commande, avec les mêmes arguments, la première échoue, mais pas la seconde. J'ai remarqué que "sh" cherchait "rm" dans "\msys\usr\bin" alors que ce dossier "usr" n'existe pas, pourtant, "msys" est bien et automatiquement monté sur "/usr" et "/" parce qu'il est bien renseigné sur le "path". Je ne sais pas si ça vous parle.

Merci.

[minnesota]

Coucou,

Me revoilà avec quelques petites nouvelles... j'en suis à l'étape du gestionnaire de tâches que je pense baser sur un modèle de fichier proche de la structure d'un fichier "inf" ou d'un fichier "ini".

Voici l'ébauche que je n'ai pas encore mise en pratique, mais ça ne saurait tarder.
Je commence avec zlib, c'est plus simple

[minnesota]

Salut

J'ai une petite question ou besoin d'une confirmation... Pour info, j'arrive vers la finalisation d'une version fonctionnelle de mon gestionnaire des tâches... La structure est en place et j'ai tenu dès le début à intégrer les prémices du support multiplateforme pour produire à la demande des binaires 32 bits ou des binaires 64 bits.

Donc je me demande s'il est possible de produire des binaires 64 bits à partir de n'importe quelles sources de Libs ? J'imagine que oui, même si ce ne sera pas optimisé, c'est juste une question d'entête PE.

Ensuite, pour ce faire, est-ce qu'il faut simplement un "cross-compiler" 32 bits, en l'occurrence Mingw64, MSYS étant toujours le même et ne changeant pas ?

Enfin, pour les architectures et plateformes 64 bits, qu'en est-il ? On utilise exactement les mêmes outils ?

Ah du coup y'a plus d'une question là

Merci.

[koala01]

Salut

J'ai une petite question ou besoin d'une confirmation... Pour info, j'arrive vers la finalisation d'une version fonctionnelle de mon gestionnaire des tâches... La structure est en place et j'ai tenu dès le début à intégrer les prémices du support multiplateforme pour produire à la demande des binaires 32 bits ou des binaires 64 bits.

Donc je me demande s'il est possible de produire des binaires 64 bits à partir de n'importe quelles sources de Libs ? J'imagine que oui, même si ce ne sera pas optimisé, c'est juste une question d'entête PE.

Pour la majeure partie des bibliothèque, oui, il "suffit" de compiler les mêmes sources en 64 bits.

Mais ce n'est pas qu'une question d'en-tête PE (bien que ce soit l'un des aspects à prendre en compte) car c'est tout ce qui touche à l'alignement en général du code binaire qui est impacté (taille des pointeurs et des types définis par l'utilisateur).

Ensuite, pour ce faire, est-ce qu'il faut simplement un "cross-compiler" 32 bits, en l'occurrence Mingw64, MSYS étant toujours le même et ne changeant pas ?

Oui, le compilateur croisé suffit. Mais tu dois te dire que tu ne pourras exécuter le résultat que sur un système qui permet l'exécution d'application 64bits, un peu à l'instar de ce qui se passe lors d'une compilation croisée linux / windows.

La plupart des systèmes 64bits ont un "mode de compatibilité" qui leur permet (sous condition) d'exécuter les applications 32 bits, mais je n'ai vu à ce jour aucun système 32bits susceptible d'utiliser des applications 64bits (et je ne crois pas que j'en verrai jamais).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Enfin, pour les architectures et plateformes 64 bits, qu'en est-il ? On utilise exactement les mêmes outils ?

Oui. Mais compilés en version 64bits et / ou multilib

[minnesota]

Oui j'en conviens, mes raccourcis étaient un peu rapides pour certains passages...

Donc si je résume, histoire d'être sûr, tu me rattraperas si c'est pas ça, alors, quelle que soit l'architecture, quelle que soit la plateforme, 32 ou 64 bits, si je veux faire du multilib, alors il faut utiliser mingw64, c'est-à-dire la version 32 bits du compilateur croisé, + MSYS, et donc travailler dans un mode 32 bits, le cas échéant de compatibilité...

Merci koala01

[koala01]

Oui j'en conviens, mes raccourcis étaient un peu rapides pour certains passages...

Donc si je résume, histoire d'être sûr, tu me rattraperas si c'est pas ça, alors, quelle que soit l'architecture, quelle que soit la plateforme, 32 ou 64 bits, si je veux faire du multilib, alors il faut utiliser mingw64,

Oui. Parce que MinGW avait porté le focus sur le compilateur susceptible de fournir uniquement des applications 32bits.

c'est-à-dire la version 32 bits du compilateur croisé,

Non!

On ne parle de compilation croisée que lorsque l'architecture cible (celle que tu indiques éventuellement par la variable --target du script de configuration, qui représente le système sur lequel l'application que tu compile est destinée à fonctionner) est différente de l'architecture sur laquelle la compilation s'effectue. Par exemple, si tu compile sous windows une application destinée à être utilisée sous androïd.

Ou l'application une fois compilée est incompatible avec l'architecture sur laquelle l'application a été compilée. Par exemple, si tu compile sous un vieux windows 32 bits une application spécifiquement compilée pour être exécutée sur un système 64 bits.

Par contre, je ne suis pas sur qu'on puisse parler d'une compilation croisée lorsqu'on compile sous windows 64bits une application pouvant fonctionner sous windows 32bits... Comme il n'y a pas d'incompatibilité, je laisserai "ceux qui savent" nous donner leur avis à ce sujet

+ MSYS, et donc travailler dans un mode 32 bits, le cas échéant de compatibilité...

Humm... C'est plus complexe que cela.

En fait, msys n'est en rien comparable avec une machine virtuelle ou avec wine sous linux.

Bon, d'accord, ils poursuivent un but similaire, mais l'approche en est tout à fait différente.

Typiquement, une machine virtuelle -- et je crois qu'il en va de même pour wine -- va mettre en place une sorte de "boite noire" totalement indépendante du système sur lequel elle est exécutée. Bon, d'accord, la machine virtuelle et l'architecture hôte partagent certains aspects comme la connexion à internet, le clavier ou la souris éventuellement, mais, en dehors de cela, tu ne pourras par exemple accéder au dossier de la machine haute qu'au travers de "lecteur réseau".

Msys est plus une sorte de "by pass" (j'utilise ce terme parce que même la notion d'émulateur ne me semble pas vraiment convenir).

Tu peux en effet lancer n'importe quelle application qui se trouve sur le se sytème hote (un windows, donc) au travers de Msys. Y compris des applications 64 bits si msys est exécuté sur une machine tournant sous une version 64 bits de windows.

La seule chose, c'est que certains outils utilisés (comme tous les outils qui pourraient intervenir au niveau du script de configuration ou au niveau de la génération de ce dernier) seront peut être effectivement exécutés en mode de compatibilité 32 bits parce que compilés sous cette forme.

Ainsi, si tu travailles sous windows 64bits, que ton compilateur est une version 64bits de MinGW, il n'y a strictement rien qui t'interdise de compiler au travers de msys -- en 64 bits -- une application que tu exécuteras sous msys et que tu pourras également exécuter de manière "classique" sous windows (que ce soit en l'appelant depuis la ligne de commande ou en double cliquant dessus).

On est donc très loin du concept de compilation croisée

[minnesota]

La dénomination de "compilateur croisé" est à nuancer en fonction de la plateforme hôte, éventuellement cible alors...

Mais dans tous les cas, lors d'un processus de compilation, j'ai pas à me soucier de la plateforme hôte, ni à m'inquiéter de savoir si c'est Mingw64 32 bits ou 64 bits qui est utilisé... juste à préciser la plateforme cible, c'est tout ? Bien sûr, Mingw64 64bits ne fonctionnera pas sur une plateforme Windows 32 bits, ça va de soi.

Sinon, est-ce qu'il y a un gros inconvénient à travailler exclusivement avec un Mingw64 32 bits sur un Windows 64 bits ?

[minnesota]

salut tout le monde,
salut koala01, d'habitude je mets que 'le' tout le monde, mais comme t'es le seul qui répond

Bon, là, j'ai téléchargé ming32-w64 de tdm... mais il y a un truc qui me chiffonne par rapport à la version classique mingw32. Sur cette dernière, les outils préfixés (mingw32-) sont identiques à ceux qui ne le sont pas. Par contre, bizarrement, sur la version ming32-w64, c'est pas le cas. Est-ce que c'est normal ? Quel "fichier" du compilateur choisir ?

sorted md5 bin of mingw32 (tdm-gcc-4.7.1)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
070ca3b2ee6fc133dab9fc1d76bd5156 *mingw32-make.exe
0909111f3f4f9dcba449072aa2a15221 *libstdc++-6.dll
1a9fdf30a8d491f33dec376bd1fa6c9d *gcc-nm.exe
1a9fdf30a8d491f33dec376bd1fa6c9d *mingw32-gcc-nm.exe
1ac621568626c88cb611321e79a35198 *libgcc_s_dw2-1.dll
22d9fdfd7dac318201f68f1d33ddf231 *gcc-ar.exe
22d9fdfd7dac318201f68f1d33ddf231 *mingw32-gcc-ar.exe
26b04616d4e73091a674e413dedda89d *mingwm10.dll
2d3411f385edd625f7e9965a4f65d120 *elfedit.exe
30ff10331e3a1fb6169f3ef65fd7d837 *gcc-ranlib.exe
30ff10331e3a1fb6169f3ef65fd7d837 *mingw32-gcc-ranlib.exe
323c18835eef405055dec2426ff40736 *addr2line.exe
440a473a6f234232ed18a9c28edd6c4d *ranlib.exe
4ed9e19f3947dccf8c5a6e096bdf5945 *c++.exe
4ed9e19f3947dccf8c5a6e096bdf5945 *g++.exe
4ed9e19f3947dccf8c5a6e096bdf5945 *mingw32-c++.exe
4ed9e19f3947dccf8c5a6e096bdf5945 *mingw32-g++.exe
517f84b648a882ede32b158e637bb774 *libquadmath-0.dll
63a548e0792578ad81e59305afc57b5b *nm.exe
6aa17cb590e3d89dd8c7d3f70e370780 *ld.bfd.exe
6f58b5638a6d8c8818fd8c3e4a31bc29 *windres.exe
73ed5793cc5b1fa9910bfb159c4b91d7 *strings.exe
7b6ec93cc04b776b5a555509869f20ce *gprof.exe
8a5dcc9181a79f6b57dc164a0c4f58d7 *gcov.exe
8cdba3662ab2a27152047b3615db9b83 *libssp-0.dll
94ec6f3acd90dc56ad59384aedccaf2d *objdump.exe
961e3a733402ddd2f485f68020c168c7 *libiconv-2.dll
9d58836efb42d5eaa318a35d78f0ca7f *as.exe
9e0e27311ac5f50fe67a6572672c6139 *objcopy.exe
adedf44488006275856102accadb0c99 *cpp.exe
b2304bb2c91ce67b0ae53432be92c585 *windmc.exe
b4ffd0002ed48698651a85a4a3c3981c *strip.exe
bd8ed3f9da36868bad98653212fe1cae *libintl-8.dll
c4182c4ee21a9c838974e0f95bde5dc5 *dllwrap.exe
c69b9274f3870d66cc6e58c239d6e993 *libgcc_s_sjlj-1.dll
c92e59e68f9915525c531b3e7fdb9f51 *ld.exe
cb72a6ec97dbe84ce729166448a759c6 *c++filt.exe
cec5f50e99ce292d84447dd040cf0f0a *readelf.exe
d58c60adabde99673448d0729b804a4d *gcc.exe
d58c60adabde99673448d0729b804a4d *mingw32-gcc-4.7.1.exe
d58c60adabde99673448d0729b804a4d *mingw32-gcc.exe
e751760fef885ff0c8bd87c4d3e5a18a *ar.exe
f449152d35185c693adc03958509ef36 *dlltool.exe
f822711a0a7e974592ad80481a3ec319 *size.exe

sorted md5 bin of mingw32-w64 (tdm64-gcc-4.8.1-3)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
0172943dbea50ddaf64558a30acc7904 *libwinpthread_64-1.dll
04bc763095b832d2d4261f563eefaa79 *libgomp_64-1.dll
0ac84d5198d0ab230f71dfba977b4e00 *libssp_64-0.dll
0d1eb14bb39cfe9636fa88c2ab189a46 *dlltool.exe
0f00e49c46c5491daf5c0b83d6e8e87b *libgcc_s_sjlj-1.dll
2fcab4dab1f5f58003490e35c40d2066 *dllwrap.exe
3373db6f6d49840e8830fd60cc49c070 *as.exe
34dfdb567b4994f29d39cda6cb02c3ca *nm.exe
3558eaff4b0d1311e5da7fd569afd964 *x86_64-w64-mingw32-c++.exe
3558eaff4b0d1311e5da7fd569afd964 *x86_64-w64-mingw32-g++.exe
39dc821c3df098fd3be1525a853d2cb9 *cpp.exe
3dd94e76260f830707e5b0af5a715d90 *libgomp-1.dll
4524cbb4032844625fccbdf235f388a7 *strings.exe
4622c133a0ecb204a45b8a5b075bce2f *ld.bfd.exe
4622c133a0ecb204a45b8a5b075bce2f *ld.exe
4ba54f5cf4ea6a5b061e09b5be17d3b1 *c++.exe
4ba54f5cf4ea6a5b061e09b5be17d3b1 *g++.exe
500c4f1ab5cbd8775ecec5856940e2f6 *gprof.exe
53be9904e6905e3111354b7d1f00ef28 *readelf.exe
53dfe179530ab2cca944dccb42a604cd *gcov.exe
61e88b0bf2626d6b49d2bf569c3887cc *libwinpthread-1.dll
6311f07c95f3df220430524f6990a043 *libstdc++_64-6.dll
6f3f07fe5649834e465740a6ceb3f25a *c++filt.exe
6f46d9308e1ea181ae74e37a49bad35c *gcc-nm.exe
737e429e24d9f610ea9988362ed31cdc *libstdc++-6.dll
76a691159414d5565514f7edad47d5b8 *objdump.exe
7d0e05381ccbdb9a7f1927d9a79f093b *x86_64-w64-mingw32-gcc-nm.exe
7f98b365c62acc3599fefa97d814b0c7 *gcc-ar.exe
81c8e847b3e94b5f8157eda6380b8271 *x86_64-w64-mingw32-gcc-ar.exe
8c36c682cc970733fce94b45de3946bc *libiconv-2.dll
8e293f8dffe36dcfffde01e6fe987890 *mingw32-make.exe
99d79c99979c2792373b53da33e34ba9 *x86_64-w64-mingw32-gcc-ranlib.exe
9b4e98d157fafacaac4af4754a3d6ec7 *libgcc_s_seh_64-1.dll
9e2287bd58ee67960052038cdbddd359 *gcc-ranlib.exe
9f5a3c5193a62d9408365e45a5dacbbe *gcc.exe
a3862b197bfe8b560820b355e9415c96 *x86_64-w64-mingw32-gcc-4.8.1.exe
a3862b197bfe8b560820b355e9415c96 *x86_64-w64-mingw32-gcc.exe
a865ef6e40bdb45205d49715ebc89d1f *strip.exe
a86c649fdc1da708cecfc1e8b1442675 *libquadmath_64-0.dll
a8a0feb0f7fcbf1bc3286b436b028771 *libquadmath-0.dll
b0b7005c9c529e5c9d4b27d45ee08b67 *size.exe
bd8ed3f9da36868bad98653212fe1cae *libintl-8.dll
bdb1d849da8b4bf579ab7f20c3ed35de *libssp-0.dll
c333feafcf544e0f8ea8f402036eca8b *gdb.exe
ce2d122c6275fcf64e06d741750c79cc *objcopy.exe
d381d2e53fd4b8919b471fd841f4b162 *libgcc_s_dw2-1.dll
d41d8cd98f00b204e9800998ecf8427e *md5.txt
e1ef93d4aab37ca033a02341658103a4 *ranlib.exe
e3bdcc085784b11822a3dee15061f526 *windres.exe
e573f76f29eb277e168985fbff42f37d *addr2line.exe
e7957caaf340cca198ce9df25f281e99 *ar.exe
f8301ebb32c7a98e9ea909f58f1c1e5b *elfedit.exe
f8e3308e9bc937f08838e75650676eca *windmc.exe

P.-S. Une petite dernière: Comment savoir si le compilateur peut produire des binaires 64 bits si l'utilisateur a déjà son compilateur ?

J'ai bien trouvé des informations utiles en tapant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc.exe -dumpspecs (|| -dumpmachine|| -dumpversion)

Autrement dit est-ce que toutes les compilations personnalisées de GCC sont cohérentes de ce côté là ? Ou un simplement contrôle de la présence, par exemple de "libquadmath_64-0.dll / libquadmath-0.dll" est suffisant ?

Exemple de sortie pour les précédentes versions sus-citées.

mingw32:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
*asm:
 
 
*asm_debug:
%{!g0:%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}} %{fdebug-prefix-map=*:--debug-prefix-map %*}
 
*asm_final:
 
 
*asm_options:
%{-target-help:%:print-asm-header()} %{v} %{w:-W} %{I*} %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}
 
*invoke_as:
%{!fwpa:   %{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}   %{!S:-o %|.s |
 as %(asm_options) %m.s %A }  }
 
*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: } 
 
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w} %{f*} %{g*:%{!g0:%{g*} %{!fno-working-directory:-fworking-directory}}} %{O*} %{undef} %{save-temps*:-fpch-preprocess}
 
*cpp_debug_options:
%{d*}
 
*cpp_unique_options:
%{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}}}}}} %{remap} %{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{!iplugindir*:%{fplugin*:%:find-plugindir()}} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
 
*trad_capable_cpp:
cc1 -E %{traditional|traditional-cpp:-traditional-cpp}
 
*cc1:
%(cc1_cpu) 
 
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %{!iplugindir*:%{fplugin*:%:find-plugindir()}} %1 %{!Q:-quiet} %{!dumpbase:-dumpbase %B} %{d*} %{m*} %{aux-info*} %{fcompare-debug-second:%:compare-debug-auxbase-opt(%b)}  %{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}}%{!c:%{!S:-auxbase %b}}  %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{Qy:} %{-help:--help} %{-target-help:--target-help} %{-version:--version} %{-help=*:--help=%*} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants} %{coverage:-fprofile-arcs -ftest-coverage}
 
*cc1plus:
 
 
*link_gcc_c_sequence:
%G %L %G
 
*link_ssp:
%{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}
 
*endfile:
%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}   crtend.o%s
 
*link:
%{mwindows:--subsystem windows}   %{mconsole:--subsystem console}   %{shared: %{mdll: %eshared and mdll are not compatible}}   %{shared: --shared} %{mdll:--dll}   %{static:-Bstatic} %{!static:-Bdynamic}   %{shared|mdll: -e _DllMainCRTStartup@12 --enable-auto-image-base}   %(shared_libgcc_undefs)
 
*lib:
%{pg:-lgmon} %{pthread:-lpthread} %{!no-pthread: } %{mwindows:-lgdi32 -lcomdlg32} -ladvapi32 -lshell32 -luser32 -lkernel32
 
*mfwrap:
 %{static: %{fmudflap|fmudflapth:  --wrap=malloc --wrap=free --wrap=calloc --wrap=realloc --wrap=mmap --wrap=mmap64 --wrap=munmap --wrap=alloca} %{fmudflapth: --wrap=pthread_create}} %{fmudflap|fmudflapth: --wrap=main}
 
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}
 
*link_gomp:
 
 
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32    %{shared-libgcc:-lgcc_s}    -lgcc    -lmoldname -lmingwex -lmsvcrt
 
*startfile:
%{shared|mdll:dllcrt2%O%s}   %{!shared:%{!mdll:crt2%O%s}} %{pg:gcrt2%O%s}   crtbegin.o%s
 
*cross_compile:
0
 
*version:
4.7.1
 
*multilib:
. ;
 
*multilib_defaults:
 
 
*multilib_extra:
 
 
*multilib_matches:
 
 
*multilib_exclusions:
 
 
*multilib_options:
 
 
*linker:
collect2
 
*linker_plugin_file:
 
 
*lto_wrapper:
 
 
*lto_gcc:
 
 
*link_libgcc:
%D
 
*md_exec_prefix:
 
 
*md_startfile_prefix:
 
 
*md_startfile_prefix_1:
 
 
*startfile_prefix_spec:
 
 
*sysroot_spec:
--sysroot=%R
 
*sysroot_suffix_spec:
 
 
*sysroot_hdrs_suffix_spec:
 
 
*self_spec:
 
 
*cc1_cpu:
%{march=native:%>march=native %:local_cpu_detect(arch)   %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
 
*shared_libgcc_undefs:
 
 
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %{!fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin:     -plugin %(linker_plugin_file)     -plugin-opt=%(lto_wrapper)     -plugin-opt=-fresolution=%u.res     %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}}     }}%{flto|flto=*:%<fcompare-debug*}     %{flto} %{flto=*} %l %{pie:-pie} %X %{o*} %{e*} %{N} %{n} %{r}    %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}}    %{static:} %{L*} %(mfwrap) %(link_libgcc) %o    %{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}    %{fgnu-tm:%:include(libitm.spec)%(link_itm)}    %(mflib)  %{fsplit-stack: --wrap=pthread_create}    %{fprofile-arcs|fprofile-generate*|coverage:-lgcov}    %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}    %{!nostdlib:%{!nostartfiles:%E}} %{T*} }}}}}}

mingw32-64

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
*asm:
%{m32:--32} %{m64:--64}
 
*asm_debug:
%{!g0:%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}} %{fdebug-prefix-map=*:--debug-prefix-map %*}
 
*asm_final:
%{gsplit-dwarf: 
       objcopy --extract-dwo 	 %{c:%{o*:%*}%{!o*:%b%O}}%{!c:%U%O} 	 %{c:%{o*:%:replace-extension(%{o*:%*} .dwo)}%{!o*:%b.dwo}}%{!c:%b.dwo} 
       objcopy --strip-dwo 	 %{c:%{o*:%*}%{!o*:%b%O}}%{!c:%U%O}     }
 
*asm_options:
%{-target-help:%:print-asm-header()} %{v} %{w:-W} %{I*} %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}
 
*invoke_as:
%{!fwpa:   %{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}   %{!S:-o %|.s |
 as %(asm_options) %m.s %A }  }
 
*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{municode:-DUNICODE} %{!no-pthread:-D_REENTRANT} %{pthread:-U_REENTRANT} 
 
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w} %{f*} %{g*:%{!g0:%{g*} %{!fno-working-directory:-fworking-directory}}} %{O*} %{undef} %{save-temps*:-fpch-preprocess}
 
*cpp_debug_options:
%{d*}
 
*cpp_unique_options:
%{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}}}}}} %{remap} %{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{!iplugindir*:%{fplugin*:%:find-plugindir()}} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
 
*trad_capable_cpp:
cc1 -E %{traditional|traditional-cpp:-traditional-cpp}
 
*cc1:
%(cc1_cpu) 
 
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %{!iplugindir*:%{fplugin*:%:find-plugindir()}} %1 %{!Q:-quiet} %{!dumpbase:-dumpbase %B} %{d*} %{m*} %{aux-info*} %{fcompare-debug-second:%:compare-debug-auxbase-opt(%b)}  %{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}}%{!c:%{!S:-auxbase %b}}  %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{Qy:} %{-help:--help} %{-target-help:--target-help} %{-version:--version} %{-help=*:--help=%*} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants} %{coverage:-fprofile-arcs -ftest-coverage}
 
*cc1plus:
 
 
*link_gcc_c_sequence:
%G %L %G
 
*link_ssp:
%{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}
 
*endfile:
%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}   crtend.o%s
 
*link:
%{!m32:-m i386pep} %{m32:-m i386pe} --exclude-libs=libpthread.a %{mwindows:--subsystem windows}   %{mconsole:--subsystem console}   %{shared: %{mdll: %eshared and mdll are not compatible}}   %{shared: --shared} %{mdll:--dll}   %{static:-Bstatic} %{!static:-Bdynamic}   %{shared|mdll: %{!m32:-e DllMainCRTStartup} %{m32:-e _DllMainCRTStartup@12} --enable-auto-image-base}   %(shared_libgcc_undefs)
 
*lib:
%{pg:-lgmon} %{!no-pthread:-lpthread} %{pthread: } %{mwindows:-lgdi32 -lcomdlg32} -ladvapi32 -lshell32 -luser32 -lkernel32
 
*mfwrap:
 %{static: %{fmudflap|fmudflapth:  --wrap=malloc --wrap=free --wrap=calloc --wrap=realloc --wrap=mmap --wrap=mmap64 --wrap=munmap --wrap=alloca} %{fmudflapth: --wrap=pthread_create}} %{fmudflap|fmudflapth: --wrap=main}
 
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}
 
*link_gomp:
 
 
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32      %{static|static-libgcc:-lgcc}  %{!static:    %{!static-libgcc:      %{!shared-libgcc:-lgcc}      %{shared-libgcc:-lgcc_s -lgcc}     }   }     -lmoldname -lmingwex -lmsvcrt
 
*startfile:
%{shared|mdll:dllcrt2%O%s}   %{!shared:%{!mdll:%{!municode:crt2%O%s}}}   %{!shared:%{!mdll:%{municode:crt2u%O%s}}}   %{pg:gcrt2%O%s}   crtbegin.o%s
 
*cross_compile:
0
 
*version:
4.8.1
 
*multilib:
. !m64 !m32;64:../lib m64 !m32;32:../lib32 !m64 m32;
 
*multilib_defaults:
m64
 
*multilib_extra:
 
 
*multilib_matches:
m64 m64;m32 m32;
 
*multilib_exclusions:
 
 
*multilib_options:
m64/m32
 
*multilib_reuse:
 
 
*linker:
collect2
 
*linker_plugin_file:
 
 
*lto_wrapper:
 
 
*lto_gcc:
 
 
*link_libgcc:
%D
 
*md_exec_prefix:
 
 
*md_startfile_prefix:
 
 
*md_startfile_prefix_1:
 
 
*startfile_prefix_spec:
 
 
*sysroot_spec:
--sysroot=%R
 
*sysroot_suffix_spec:
 
 
*sysroot_hdrs_suffix_spec:
 
 
*self_spec:
 
 
*cc1_cpu:
%{march=native:%>march=native %:local_cpu_detect(arch)   %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
 
*shared_libgcc_undefs:
 
 
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %{!fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin:     -plugin %(linker_plugin_file)     -plugin-opt=%(lto_wrapper)     -plugin-opt=-fresolution=%u.res     %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}}     }}%{flto|flto=*:%<fcompare-debug*}     %{flto} %{flto=*} %l %{pie:-pie} %{fuse-ld=*:-fuse-ld=%*}    %X %{o*} %{e*} %{N} %{n} %{r}    %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}}    %{static:} %{L*} %(mfwrap) %(link_libgcc) %{!nostdlib:%{!nodefaultlibs:%{fsanitize=address:}     %{fsanitize=thread:}}} %o    %{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}    %{fgnu-tm:%:include(libitm.spec)%(link_itm)}    %(mflib)  %{fsplit-stack: --wrap=pthread_create}    %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} %{!nostdlib:%{!nodefaultlibs:%{fsanitize=address:%{static-libasan:-Bstatic} -lasan %{static-libasan:-Bdynamic}    %{static:%ecannot specify -static with -fsanitize=address}    %{fsanitize=thread:%e-fsanitize=address is incompatible with -fsanitize=thread}}    %{fsanitize=thread:%{static-libtsan:-Bstatic} -ltsan %{static-libtsan:-Bdynamic}    %{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or -shared}}}}}     %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}    %{!nostdlib:%{!nostartfiles:%E}} %{T*} }}}}}}

Merci...

[minnesota]

à noter aussi que "\tdm64-gcc-4.8.1-3\bin\gdb.exe" est en version 64 bits dans ce package...

[koala01]

Pour ce qui est des noms, c'est uniquement lié à la séquence de compilation.

Généralement, la génération d'une liste d'outils pour la compilation croisée se fait dans un ordre assez particulier qui correspond peu ou prou à

1. compilation de binutils
2. compilation d'une version croisée de gcc pour l'architecture cible (--target=)
3. compilation des bibliothèques run-time
4. compilation d'une version correspondant à l'architecture hôte (--host=)
5. re-compilation de binutils (en utilisant le "nouveau" compilateur)

Lorsque le seul compilateur dont tu disposes est un compilateur non croisé (par exemple, susceptible de ne fournir que des exécutables 32bits), le processus de compilation va générer un exécutable 32bits qui sera un compilateur capable de générer des exécutables 64 bits. C'est cet exécutable 32bits qui sera utilisé pour la fin du bootstrap et qui permettra au final d'obtenir un compilateur 64bits susceptible de générer aussi bien des exécutables 32bits que 64bits. Il est donc "logique" que tu aies une somme de contrôle différente pour le compilateur croisé et pour le compilateur hôte. C'est sans doute ce qui s'est passé pour tdm-4.7 qui aura vraisemblablement été compilé avec une version 32 bits de gcc

Par contre, si ton compilateur "d'origine" est déjà capable de fournir des exécutables 64bits, le compilateur croisé sera déjà un exécutable 64bits. Comme le code est strictement identique pour le compilateur croisé que pour le compilateur hôte, il est "normal" que le compilateur hote ne soit jamais qu'une copie strictement identique du compilateur croisé. Et il est donc tout à fait normal que les deux sommes de contrôle soient strictement identique. C'est sans doute ce qui s'est passé pour tdm-4.8 qui aura vraisemblablement été compilé avec la version 64bits de tdm-4.7

Pour savoir si un compilateur est capable de compiler des exécutables 32 ou 64 bits, il "suffit" le plus souvent d'essayer de compiler en passant l'argument -m32 ou -m64 au compilateur. Le premier est censé demander au compilateur de générer un exécutable 32bits, le second est censé demander de générer du code exécutable 64bits.

Tu peux également effectuer une vérification "manuelle" en recherchant les versions des dll dans le dossier d'installation. Typiquement, les dll seront placées dans deux dossiers différents : un pour la version 32bits, l'autre pour la version 64bits (au passage, le script d'installation foire parfois pour l'une des dll qu'il installe dans <dossier_racine>/bin en mode multilib et copie une dll 32 bits dans le dossier qui normalement ne contient que des dll64... Quant aux dll 32bits, elles doivent être copiées a mano dans un dossier séparé )

Tu trouveras également trois dossier lib dans <dosssier_racine>/<architecture> : lib_32 qui contient les bibliothèque32 bits, lib_64 qui contient les bibliothèques 64bits et lib qui est la copie d'un des deux autres.

Tu devrais enfin pouvoir trouver dans <dossier_racine>/lib/gcc/<version>/<architecture> un dossier ( 32/ ) qui contient les même bibliothèque que le dossier <dossier_racine>/lib/gcc/<version>/<architecture>, mais dans "l'autre version" (32bits).

Note au passage que le script d'installation de target-libgcc foire généralement et place libgcc_s.a (si elle est créée) dans les dossiers <dossier_racine>/lib/gcc/<version>/lib_32 et <dossier_racine>/lib/gcc/<version>/lib_64 au lieu des dossiers <dossier_racine>/lib/gcc/<version>/<architecture> et <dossier_racine>/lib/gcc/<version>/<architecture>/32.

Je constate de tdm a renommé les dlls pour y inclure la version (_64). Cette distinction n'apparait, à ma connaissance, pas quand tu compiles toi-même Gcc

[minnesota]

salut koala01, merci

Je me demande aussi s'il n'y a pas une inversion entre les deux mingw dans tes deux premiers paragraphes. J'ai fait un test rapide avec mingw32-w64 (tdm64-gcc-4.8.1-3) qui par défaut produit bien du 64 bits, mais quand je mets l'option "-m32", le linker ne trouve pas les libs 32 bits, par exemple msvcrt...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc -m32 -o simple_test.exe simple_test.c

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