Version imprimable
Bonjour,
je compile deux fois les mêmes sources avec GCC, je calcul un CRC sur les binaires obtenus et je trouve deux clés différentes.
Je me suis dit que c'était du à un changement de date/heure.
Est-ce la bonne explication? Sinon quelle est l'explication?
Comment obtenir deux fois le même binaire en compilant les mêmes sources?
Précisions:
- il n'y a pas de tag style CVS "$date"
- je n'utilise pas d'IDE, mais la commande: "gcc hello.cpp -o hello"
dans le format ELF il y a le timestamp. a chaque fois que tu recompiles tu vas avoir un exe légèrement différent. Essaye de faire un diff binaire (je ne connais pas de programme pour ca mais ca existe)
J'ai le même problème sous Windows.Citation:
Envoyé par screetch
Le problème est que je dois être capable de générer toujours le même binaire à partir de sources versionées correspondant à une version de configuration donnée. Cela fait partie des exigences qualité de mon entreprise.
PS1: je n'ai pas le choix sur l'algorithme de CRC qui est un RIPEMD 160 base 32.
PS2: on s'assure aussi de l'integrité des sources avec un CRC. Et la chaine d'outil de developpement est sous gestion de conf...
Quand on boostrap gcc, il fait une comparaison de binaires a la fin. Tu peux éventuellement récupérer sa méthode.
en fait j'ai vérifié mon "parser d'executable", il est portable windows (Portable Executable) et Linux (Elf), et je me suis trompé. sous linux, il n'y a pas de timestamp sur le fichier binaire (peut etre les infos de débug? mais je ne crois pas). c'est sous windows qu'il y a un timestamp.
malheureusement pas possible de vérifier ce timestamp, tu risques de devoir faire un peu a la paluche
ce que e pense etre le plsu simple (et le plus portable) :
objdump -s "exe" te donne le contenu des sections (exit le header et tout ca), vérifie que les deux contenus sont identiques... au header près.
Faut aussi qu'ils arrêtent de demander des choses quasi-impossibles, ou alors filer les billes nécessaires (= le temps et l'argent) pour avoir la politique de leurs moyens...Citation:
Envoyé par KeeeN
La seule solution dont j'ai entendu parler, mais jamais vue appliquer, est un rétropatch sur l'exécutable produit en y injectant de force le timestamp du fichier d'origine (le fichier projet principal, par exemple, ou un fichier dédié à ça dont le seul intérêt est de stocker une date/heure). Pas trivial de prime abord, donc...
Surtout qu'il y a des outils qui se servent de ce timestamp adossé à un gestionnaire de code source et l'intégration continue pour fournir le code source correspondant à la version de l'exécutable qui posent problème.
Encore une solution de l'ingénierie qualité complètement obsolète.
http://msdn.microsoft.com/en-us/magazine/cc163563.aspx
Si je comprend bien, nous n'avons pas de solution avec GCC pour avoir un binaire sans time stamp. Je ne vais pas changer les suite d'outils utilisée car je ne fais que récupérer un projet existant.
Donc la seule solution que j'ai pour coller avec l'exigence qualité est de modifier cette exigence.
Est-ce bien ça?
J'ai encore un mois pour trouver une solution, après je modifie l'application de l'exigence ou l'exigence, pour ce projet.
je vais me repeter mais je pense que la solution que j'ai proposé fonctionne
Citation:
Envoyé par screetch
Elle marche dans le cas où j'ai deux binaire à comparer.Citation:
Envoyé par screetch
Dans mon cas j'ai en gestion de conf:
- des sources
- un CRC calculé sur le binaire généré à partir des sources
Je veux récupérer ces sources et régénérer un binaire et trouver le même CRC. Car c'est la procédure de qualité qui me l'impose.
PS: le problème de cette procédure est qu'on vérifie la chaine de production par le résultat final, en même temps que l'on vérifie le produit, via le CRC sur les binaires. Or si nous gérions en configuration la chaine de production et les sources, nous pourrions assurer séparément que nous avons les même outils et trouver un autre moyen de s'assurer que nous avons le même produit. A l'heure actuelle si un outil de la chaine de production n'existaient plus en dehors de l'entreprise, nous serions ni**és. Car pour chaque version du produit nous n'avons que les versions des outils de la chaine de production.
Salut,
C'est cocasse car cela signifie que vous avez une exigence très (trop) forte dans votre processus qualité (le CRC sur les binaires) mais que vous n'avez pas les moyens de le garantir (pas de gestion des outils de production). Ca se mord la queue et si vous trouvez une solution, je crains que ce ne soit qu'une bidouille qui 'colle' au PAQ mais qui sera loin d'assurer réellement l'objectif.
Bon courage.
C'est peut-être possible... sur les binaires strippés. si je strippe mes binaires sous Linux, je n'ai aucun problème pour vérifier que le md5 du binaire strippé est identique au md5 du binaire référence strippé. Je compile le binaire référence sous OpenSUSE et le binaire à tester sur Ubuntu 9.04 dans Virtual Box.Citation:
Envoyé par 3DArchi
Alor si j'y arrive... :)
Cela dépend du format d'exécutable et de l'OS, de toutes façons. Et dans plusieurs cas, c'est totalement insoluble sur un binaire "brut de fonderie" issu du linker : il faut soit ignorer certains octets, soit stripper, soit compiler depuis la même arborescence, soit ... que sais-je encore ??Citation:
Envoyé par Emmanuel Deloget
Bref, ce n'est pas fiable pour un sou. Il vaut mieux mettre les sources de façon blindée en gestion de configuration (projet, makefiles et ressources incluses bien entendu), et corréler ça avec une version d'un outil de production que l'on met lui aussi en gestion de configuration.
Surtout qu'à l'heure actuelle, avec les machines virtuelles, il est très simple de conserver un tel outil fonctionnel sans mobiliser un PC complet.
J'ai du mal à comprendre le but de la procédure qualité.
S'assurer que des binaires n'ont pas changé d'une version à l'autre ? --> pourquoi ont-ils été recompilés si le source n'a pas changé ?
S'assurer que la compilation s'est bien passée ? --> si tu compiles tout sur la même plateforme, tu prends le risque que le compilateur génère de la merde à chaque fois, si tu compiles sur plusieurs plateformes différentes, ça risque bien de n'être jamais identique.
Dans tous les cas, ça sera spécifique à ta plateforme, et la comparaison par section est la seule qui me parait possible de donner des résultats.
Généralement, le but est de s'assurer que les sources qu'on utilise permettent bien de générer le binaire qui est utilisé par le client. Si on ne peut pas effectuer cette vérification, comment être sur qu'un vieux projet dont on aurait plus la version binaire et qu'il faut livrer à nouveau au client (parce que lui aussi aurait perdu les binaires) est bien ce qu'il attends ?Citation:
Envoyé par white_tentacle
C'est pour ça qu'on met en place cette stratégie de machine virtuelle, qui contient l'environnement de développement complet et l'ensemble des outils utilisés pour générer les binaires. On s'assure ainsi qu'on est capable à tout moment de regénérer des binaires qui sont exactement similaires à ceux déjà livrés.
L'idée de tagger les sources avec un label n'est pas suffisante si on a pas de contrôle sur les outils de dev utilisé. Ceux ci peuvent introduire des artefacts qui peuvent poser problème (par exemple, la lib standard peut évoluer ; une nouvelle optimisation dans la dernière version d'un compilateur peut se retrouver à ajouter un bug dans le programme à cause de conditions très particulières ; etc).
Merci d'avoir précisé ce que j'avais en tête :pCitation:
Envoyé par Emmanuel Deloget
Jusqu'à ce qu'on me prouve le contraire (ce qui me plairait!), il n'y a donc AUCUN MOYEN de générer 2 binaires identiques avec GCC.
PS: Je trouve quand même dommage de ne pas pouvoir générer 2 fois le même binaire à partir de même sources, sur la même plateforme, avec les même outils...
Ce ne sont pas les mêmes potentiellement, vu qu'ils ont été générés à des dates différentes... Voire depuis des arborescences de répertoires différentes.Citation:
Envoyé par KeeeN
Au contraire, je trouve que c'est un "plus" pour ma part : il est impossible de truander le client en lui fournissant le même binaire pour l'enfumer, on est obligés de régénérer l'exécutable et/ou ses DLL, et donc laisser une trace de ladite régénération... Qui impose, normalement, une validation en bonne et dûe forme derrière étant donné que le binaire est modifié ! ;)
Salut,Citation:
Envoyé par Mac LAK
J'ai tendance à partager cette vision. Si tu veux donner au client le même exécutable, alors tu dois aller le chercher dans une gestion de conf. Mais le re-générer même avec la même conf et avec les mêmes sources ... ce n'est pas le même exécutable. Et puis, que se passe-t-il si quand tu veux regénérer tu n'as plus de plateforme matérielle sur laquelle tu peux faire tourner tes outils de génération ? Va voir ton R.A.Q. et dis lui : je crois que ça va pas être possible, non, non. Et propose un gestion de conf du livrable directement.
Sans oublier les symboles, qu'il faut générer dans un fichier à part, du coup.Citation:
Et propose un gestion de conf du livrable directement.
je vais encore me répéter mais le plus proche de ce que tu peux faire c'est ce que j'ai donné, a partir du binaire compilé tu peux ectraire les sections et claculer le CRC. si tu n'as que le CRC c'est que la procédure est con comme ses pieds, et ca ne marchera jamais.Citation:
Envoyé par KeeeN