Bonjour (cc me Je ne suis pas inscrit sur la liste).
Ayant lu les deux articles suivants : http://blog.flameeyes.eu/2008/11/14/problems-and-mitigation-strategies-for-as-needed http://udrepper.livejournal.com/19395.html et après avoir été sollicité par un collègue développeur sur le projet FreeWRL, j'ai constaté que le paquet dont je m'occupe (freewrl) pouvait bénéficier de l'option --as-needed de ld. De plus l'idée était de savoir pourquoi la compilation sous Gentoo avec cette option échouait. On a réglé le problème dans le contexte du développement (upstream) sans toutefois activer l'option par défaut. Je me suis alors naturellement posé la question : vais-je activer l'option dans la compilation du paquet (debian/rules) ? Voici la suite : Raphael Hertzog <hert...@debian.org> - Thu, 19 Feb 2009 17:53:19 +0100 >On Thu, 19 Feb 2009, Michel Briand wrote: >> si je comprends bien c'est d'abord un build normal qui est opéré, et >> lors de la finalisation alors on peut utiliser --as-needed. > >Heu non, c'est un option de ld donc elle s'emploie à la l'édition des >liens de la phase de compilation. > Je voulais dire : c'est une option optionnelle ;)... C'est à dire que le développeur peut ne pas y prêter attention (build normal). Le mainteneur peut venir à la rescousse (finalisation) en apportant une expérience de l'empaquetage et du déploiement. Et proposer alors cette option (et régler les problèmes quelle génère). D'ailleurs le premier article souligne que la communication entre mainteneur et développeur doit être bonne pour que le système de compilation soit compatible avec l'option (du ressort du développeur). >> Donc c'est une option du responsable de l'archive et non du mainteneur >> du paquet, n'est-ce pas ? > >Le mainteneur Debian peut toujours rajouter cette option dans les LDFLAGS >pour l'employer si l'auteur amont ne l'utilise pas. > Ma question était donc : doit-on statuer sur son utilisation de façon générale. Ou est-ce une option à choisir individuellement, par paquet. >> Le gain évident de l'utilisation de cette option est de ne pas lier le >> programme à des bibliothèques secondes qui peuvent disparaître ou >> apparaître suivant les évolution des bibliothèques primaires. > >Pas besoin d'aller aussi loin, des paquets employant pkg-config recoivent >plein de bibliothèques dans les flags de compilation et toutes ne sont pas >nécessaires, certaines sont optionnels en fonction de l'usage que l'on >fait et --as-needed permet de ne pas le faire apparaître dans le binaire >final si elle ne sont pas nécessaires. > Tout à fait d'accord. Ceci souligne la pagaille générée par l'utilisation de pkg-config. Néanmoins, faute de mieux, je l'utilise et j'en suis globalement satisfait. Si une meilleure méthode s'impose je l'adopterai volontiers. >> Cela me semble un gain énorme surtout s'il n'y a pas de contrepartie >> (effet de bord néfaste)... > >Il y a quelques risques/complications mais ils sont maigres de ce que >j'ai retenu (l'ordre d'appartion des flags -l<lib> sur la ligne de >commande est notamment important pour le fonctionnement de --as-needed). > Remarque très importante à mon avis. L'utilisation des outils pkg-config, automake et libtool ne remplacera pas une bonne connaissance d'UNIX. D'ailleurs ces outils, même s'ils sont particulièrement utiles, sont très gourmands en temps : on se rend compte à l'usage qu'on passe facilement 10x plus de temps à mettre au point un système de compilation auto* plutôt que d'écrire un Makefile unique et bien structuré comme le suggère, le propose Peter Miller dans cet article : http://miller.emu.id.au/pmiller/books/rmch/ -- Michel -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
