Bonjour,
nous utilisons actuellement cmake et distcc sur nos postes de développement pour générer notre projet.
Je ne maitrise pas bien cmake, mais je suis déjà mis les pieds dedans pour deux-trois modifications.
Afin de pouvoir générer des patchs versionnés de notre projet, j'aurai besoin de m'assurer que les librairies et binaires aient le même md5sum (ou autre méthode je suis preneur), à chaque génération que je pourrait lancer, si aucun changement dans le code, dans les paramètres de compilation, etc ..
En gros, je voudrais être certain que si je compile maintenant, et disons dans 10 jours, sans aucun changement dans le projet ou autre, j'aurai mes binaires avec le même md5sum.
Est-ce faisable ? Y-a-t'il un FLAG de compilation pour ça ? Est-ce que c'est gcc qui gère ça tout seul ?
Merci d'avance pour votre aide.
Sylvain
# oui
Posté par NeoX . Évalué à 2.
si rien n'a changé, alors la sortie DOIT etre la meme
donc le md5sum SERA le meme
[^] # Re: oui
Posté par gouttegd . Évalué à 7.
Euh, quand je vois le travail que représente le projet Reproducible Builds de Debian, j’ai un doute sur le fait que ce soit si simple.
Notamment :
[^] # Re: oui
Posté par Zenitram (site web personnel) . Évalué à 1.
Tu veux dire qu'en 10 jours, la date et heure de build (qu'on peut retrouver dans les binaires) ne change pas, qu'il n'y a jamais d'update de sécurité? etc…
Oui… si rien ne change, mais voila…
[^] # Re: oui
Posté par sygirard . Évalué à 1.
Le système Linux sur lequel nous travaillons est verrouillé au niveau des mises à jour pour être en phase avec les PC qui sont chez les clients qui ne sont pas forcément connectés à internet pour d'éventuelles mises à jour …
# Infos supplémentaires
Posté par sygirard . Évalué à 1.
Je viens de faire des tests depuis hier.
Nous avons des scripts qui permettent de générer un installer de base du projet ou un patch versionné.
Dans les deux cas on compile tout le projet, et on fait le md5 des fichiers qui nous intéressent juste après la compilation.
Dans le cas où je lance ces scripts en local sur mon poste (compilation distribué activée), j'arrive à avoir le même md5 pour les binaires et librairies.
Mais dans le cas où je lance ces scripts par Jenkins, mode normal de livraison logiciel chez nous, et bien j'ai des différences.
[^] # Re: Infos supplémentaires
Posté par NeoX . Évalué à 2.
tu veux dire que 2 lancements de compilations, du meme projet, à partir de jenkins ne donnent pas le meme binaire (md5) ?
[^] # Re: Infos supplémentaires
Posté par sygirard . Évalué à 1.
Et bien apparemment oui, puisque tu vois, je me suis connecté sur la machine sur laquelle est exécuté le script du job Jenkins, en tant qu'utilisateur que l'on a créé spécifiquement pour ça.
On utilise "hg" comme gestionnaire de projet.
Je me suis donc rendu dans le home de l'utilisateur, puis dans workspace, puis le nom du job Jenkins.
J'ai effectué les mêmes manipulations que le script, à savoir :
hg pull http://…
hg update -C LE_TAG_POUR_MA_VERSION
puis lancement du script de compilation et génération.
J'ai donc fait ça hier soir depuis mon terminal connecté sur l'utilisateur spécifique pour les job Jenkins.
J'ai récupéré les md5 de mes fichiers.
J'ai refais exactement les mêmes manipulations ce matin depuis mon terminal.
J'ai comparé les md5, et mise à part deux lib (ce qui est normal), ils sont tous similaires.
Hors, si je lance deux fois mon Job jenkins avec le même TAG, j'ai pas les mêmes md5. C'est du délire.
Je refais le test pour confirmer, histoire de pas passer pour un clown, mais je suis presque sur que les md5 étaient différents. Pas tous, certes, mais l'intégralité de mes lib sur.
Je test et je reviens.
[^] # Re: Infos supplémentaires
Posté par sygirard . Évalué à 1.
Bien, j'ai réussi à faire deux compilations du même projet, même TAG avec le job Jenkins, et j'ai les mêmes MD5.
Le problème ne vient donc pas de Jenkins. Dommage je trouve pas de smiley tête de clown ^
Je pense que ça vient donc de nos patchs de numéro de version que l'on fait dans les sources cpp d'une librairie qui impactent plus que ce que je pensais.
Désolé, je pense vous avoir dérangé pour rien.
Je reviens vers vous pour dire ce qu'il en est.
Merci encore.
[^] # Re: Infos supplémentaires
Posté par sygirard . Évalué à 1.
Je précise que ça peut être que cette histoire de patch de version car entre les deux TAG mercurial et donc entre les deux générations Jenkins, aucune modification de code.
[^] # Re: Infos supplémentaires
Posté par sygirard . Évalué à 1.
En y réfléchissant, l'histoire du patch de version ne peut pas vraiment être la cause.
Car d'une part le numéro de version ne change pas, d'autre part, on intègre dans la librairie la date/heure de génération.
Et comme vu ci-dessus, deux génération qui se suivent, avec le même TAG mercurial, génèrent les mêmes MD5, excepté pour la fameuse lib qui contient la version et la date de génération.
Il doit y avoir une différence entre mon générateur d'installeur full et mon générateur de patch.
DONC LAISSEZ TOMBER LA QUESTION, JE PENSE QUE TOUT CE JOUE DANS MES SCRIPTS ET PAS PAR RAPPORT A CMAKE/GCC.
Merci encore et désolé …
[^] # Re: Infos supplémentaires
Posté par NeoX . Évalué à 2.
de rien
parfois exposer un souci permet de mieux comprendre son probleme,
et d'y trouver soi meme une solution. ;)
# Trouvé
Posté par sygirard . Évalué à 3.
Pour infos, et pour ceux que ça intéresse, j'ai trouvé le problème.
Pour la génération d'un installeur complet et d'un patch j'utilise un job Jenkins différent, et donc un workspace différent (oui j'utilise mercurial, rappelez vous, et pour la première utilisation d'un job je fais un clone et le workspace prend le nom du job Jenkins).
J'ai eu une idée, et pour la tester j'ai fait en sorte de produire l'installeur et le patch dans le même job jenkins, et donc dans le même workspace.
Et là Oh Miracle !!!!! j'avais juste mes 2 librairies impactées dans le patch … Ça marche !!!!
P… de rpath
Je fais mes md5sum avant de les virer … ça pouvait donc pas marcher.
On ne s’ennuie jamais ;-) J'adore mon boulot ^
[^] # Re: Trouvé
Posté par sygirard . Évalué à 1.
J'ai dis une connerie. C'est pas les rpath qui sont différents.
C'est les chemins que l'on retrouve dans les logs d'erreurs.
Genre /home/../../../maLib.so:21 : ERROR …
C'est la seule chose qui change si compilé dans un job jenkins différent.
De plus, si j'utilise la commande "readelf -h", seule la valeur de "Start of section headers" est différente. Alors que tout est identique pour la même lib lorsque je compile mon installeur et mon patch dans le même job Jenkins.
Désolé si je blablate pour rien dire, juste que j'essaie de trouver ce qui me fait cette différence, uniquement parce que le workspace où je compile est différent (seulement le path, puisque les variables d'environnement sont identiques)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.