Bonsoir à tous.
Bon voila, j'en suis toujours à essayer de faire d'un beau serveur tout neuf (un quadri-Xeon à 3Ghz chacun, tout de même) sous Fedora Core 2, une machine dédiée au développement. Cela avait commencé ici: https://linuxfr.org/forums/19/3820.html(...)
Jusqu'à présent, cela se présente bien, mais je compte construire une flopée (enfin au moins trois) de compilateurs gcc, pour bâtir des exécutables destinés à différentes plateformes, dont Win32.
Cela commence donc par la mise en place des outils de binutils, eux-aussi recompilés à partir des sources. Et a ce sujet, un outil fait partie de cette suite: windres, bien pratique pour éditer les ressources Windows.
Le problème: Impossible d'activer la compilation et l'installation de cet outil (pas plus que dlltools, tiens, pendant que j'y pense). J'ai lancé la config/compilation comme suit:
$ cd compildir
$ ../binutils-2.15/configure --enable-64-bit-bfd --enable-targets=all --enable-shared --prefix=/LeRepertoireQuiVaBien
Voila. Y a-t-il quelque chose qu'il faille rajouter ? J'ai passé l'après-midi plongé dans les docs et les README disséminés à travers les méandres de la grosse archive.
Merci d'avance.
Forum Programmation.c binutils: Recherche windres désespérement !
30
sept.
2004
# ...
Posté par snt . Évalué à 2.
je suis sans doute incapable de t'aider mais les gens qui peuvent auront peut etre besoin des messages d'erreur suite au make.
[^] # Re: ...
Posté par Obsidian . Évalué à 2.
Il y a une mise en garde dans la doc du binutils concernant le fait que l'outil n'est pas systématiquement distribué, mais dans mon cas il est, et il n'y a rien concernant une éventuelle option à passer ...
[^] # Re: ...
Posté par _seb_ . Évalué à 2.
Le configure, il dit pas quelque chose à ce propos ?
[^] # Re: ...
Posté par Obsidian . Évalué à 3.
Oui, j'ai nagé à travers tous les Makefile et ./configure, tous générés par autoconf évidement, soit 10000 lignes minimum. J'ai essayé de changer quelques paramètres etc ...
La solution est la suivante:
S'il est conseillé de mettre une directive "--target=", tant à la construction de gcc qu'à celle des binutils, l'ignorer provoque la construction d'une suite d'outils natifs, destinés à traiter des fichiers au format adaptée à la machine sur laquelle on est censé travailler, ce qui est en général ce que l'on veut.
Or: passer cette option provoque également l'ajout d'un préfixe devant tous les noms des outils, préfixe correspondant à la cible. Ex "i686-pc-linux-gnu-ar", "i686-pc-linux-gnu-ld" pour binutils, ou "i686-pc-linux-gnu-gcc" dans le cas des compilateurs de gcc. Il est d'ailleurs précisé dans la doc que lorsque l'on invoque gcc -arch=xxxxx, c'est en fait ces exécutables qu'il va chercher.
Mais en outre, ne pas préciser de cible génère non seulement des outils natifs mais aussi sans préfixe ! Et c'est eux qui vont être invoqués en premier, même en passant une option "--arch" (dans ce cas, les suivants sont appelés par ces premiers). C'est aussi ce qui provoque la prise en charge par défaut de la machine locale.
Cela veut déjà dire qu'il est préférable de construire d'abord tous les outils et compilateurs pour toutes les plateformes croisées, et seulement enfin, les outils et compilateurs natifs.
La clé du mystère:
S'il faut effectivement créer une suite de compilateurs, un par cible (ce qui, déjà, en soi, n'est pas clair: cela ne le devient qu'implicitement, au moment où l'on apprend que passer une architecture en directive appelle l'exécutable correspondant), cela est loin d'être évident pour binutils, qui reçoit l'option --enable-targets=all, contrairement à gcc. Cette option laisse penser que l'on peut bâtir une suite d'outils visant toutes les cibles.
En fait c'est faux: Cette option ne sert qu'à activer l'accès aux différentes cibles, volontairement restreintes. Il faut en plus ajouter "--enable-64-bit-bfd" pour étendre cette sélection aux cibles 64bits telles que Sun Solaris2 sur Sparc64 (v9).
Cela implique donc de construire binutils exactement comme gcc, les deux suites partageant les mêmes répertoires, ce qui est une bonne chose. Donc reconstruire une version de binutils pour chaque cible.
C'est là que tout se dénoue: chaque build de binutils ciblant une plateforme particulière, et windres ne servant qu'à manipuler les fichiers Windows, cet outil ne sera compilé que si binutils cible explicitement cette plateforme ! Même si les sources de l'outil se trouve dans le package.
Fini ? Pas encore tout-à-fait: binutils va encore faire appel à votre intuition:
Déjà, créer un exécutable Windows n'est l'affaire que du linker "ld", et pas du compilateur, qui lui ne doit produire que du code objet pour le processeur sur lequel le système de Redmond doit tourner.
Ensuite, à votre avis, quel sera le nom de la cible ? Win32 ? Nan, Windows contamine aussi les machines 64 bits.
Il faut en fait se souvenir qu'à la naissance de Windows, sont apparus les formats NE (New Executable), puis PE (Portable Executable), encapsulés au sein d'un fichier Exe MS-DOS standard, lequel ne servant plus qu'à écrire "This program cannot run in DOS mode" à l'écran. D'ailleurs, le même format sera utilisé sur toutes les architectures, y compris non-PC. En cherchant un peu dans les BFD de binutils, on trouve donc pe-i386 et pei-i386.
D'où une cible qui marche: i386-pc-pe, pour ratisser le plus large possible.
Après l'effort, la récompense: Cette procédure fonctionne pour toutes les cibles. Vous pouvez donc essayer l'impressionnante palette de processeurs et de plateformes reconnus par gcc, et n'êtes plus obligés de débourser entre 10000 et 20000 francs ( http://fr.kelkoo.com/search.jsp?catId=100164013&siteSearchQuery(...) ) pour profiter d'un compilateur performant, et surtout vous n'avez plus de raisons de rebooter:
Un seul tarball, un seul makefile, et votre application fonctionnera partout. Quelques NFS/SMBmount judicieux, voire des montages de partitions, et tout votre pôle de développement sera centralisé !
Bon je poste tout cela en astuce ou j'écris un HOWTO ? :-)
[^] # Re: ...
Posté par beb . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.