Salut, j'essaie tant bien que mal de compiler un binaire qui puisse tourner sur les distributions les plus célèbres à savoir Ubuntu, Fedora et OpenSuse. Sauf que c'est un vrai casse tête chinois au niveau des dépendances. Je compile sous ArchLinux et forcément j'ai en main les derniers versions de mes libs mais lorsque je décide de lancer mon binaire, l'une de ces distributions fournie jamais la bonne version de la lib.
Je me suis efforcé de rester en dynamique pour alléger au mieux le binaire mais j'hésite vraiment mettre des libs en statiques pour ne pas me prendre la tête sur chaque distribution. Par exemple, sous Ubuntu je rencontre un souci avec GLEW qui est fourni par défaut en 1.8 alors que j'ai besoin de la 1.9. Sous Fedora, c'est JPEG-TURBO qui me prend la tête car fourni en 6 et non en 8 (la 9 est sortie !!!). Par contre sur d'autres distributions moins connue, pas de soucis, ça tourne au poil. Je n'ai pas encore testé OpenSuse mais je appréhende déjà…
Bref, j'en viens à ma question, est-ce vraiment un problème de lier statiquement quelques librairies au binaire pour unifier le tout sans devoir imposer à l'utilisateur d'aller compiler ou bidouiller son installation d'autant plus qu'il s'agit d'un binaire qu'on lancera qu'une fois ?
Merci pour vos réponses.
# bah...
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Salut,
Si ton but c'est la compatibilité avec un maximum de systèmes différents, tu n'as pas le choix, il faut compiler en statique.
Mais ce serait mieux de proposer différents paquets…
[^] # Re: bah...
Posté par shingo (site web personnel) . Évalué à 1.
Oui, je veux un maximum de compatibilité pour que les utilisateurs n'aient à passer du temps à configurer pour lancer le binaire. En revanche, oui j'avais penser à proposer une version non statique pour ceux qui veulent se débrouiller comme des grands car j'ai beau réfléchir dans tous les sens, je ne vois pas d'autres solutions.
Merci en tout cas.
[^] # Re: bah...
Posté par JGO . Évalué à 6.
Le « problème » avec la version statique c'est que l'utilisateur ne bénéficie pas des mises à jour de sécurité des bibliothèques. Il y a déjà eu des CVE sur libjpeg-turbo.
# Cree des wrappers
Posté par podoc . Évalué à 0.
Le mieux dans ce genre de cas est d'utilisé des wrappers
Ces wrappers se chargeront de charger dynamiquement (Cad à l'exécution et non pas au chargement du programme).
Ces wrappers utiliseront la fonction dlsym() pour charger la bibliothèque qui va bien.
Avantages à l'utilisation des wrappers.
1 Inconvénient
* Ca rajoute une couche pour l'utilisation de tes données
Personnellement c'est ce que je fais dès que je suis amener à utiliser une bibliothèque externe sur laquelle je n'ai pas la main (Typiquement ton cas).
[^] # Re: Cree des wrappers
Posté par Mme Michu-cide . Évalué à 1.
Concrètement, ça se présente comment?
Quand on voit la façon dont sa casse entre quelques version d'une même biblio, ça ne me semble pas super robuste.
[^] # Re: Cree des wrappers
Posté par Batchyx . Évalué à 1.
Ça va bien tant que tu est en face de bibliothèques en C. en C++ dès que tu utilise une classe dans ta bibliothèque, tu peux oublier dlopen().
[^] # Re: Cree des wrappers
Posté par podoc . Évalué à 0.
C'est qu'avec des bibliothèques en C++ c'est plus embétant pour connaitre le nom du symbole, mais c'est faisable.
# Tu réponds déjà indirectement à ta question
Posté par kadalka . Évalué à -8.
Arch Linux utilise en général les dernières versions des logiciels
(derniers libs par exemple)
Or, si je lis ton post, je constate que tu voudrais que les logiciels que tu compiles avec Arch Linux fonctionne sur toutes les distributions que tu utilises.
Je ne vois pas comment tu pourrais éviter la compilation statique si tu veux avoir la possibilité d'utiliser ce que tu as compilé dans sa dernière version.
Personnellement, je conseille la compilation statique dès l'instant où on envisagerait d'utiliser le même binaire un peu partout…
Sur le plan technique, il me semble que cela ne pose pas de grave problème : de mon côté AUCUN problème.
[^] # Re: Tu réponds déjà indirectement à ta question
Posté par arnaudus . Évalué à 4.
Bah évidemment que si, il y a des problèmes, autrement les distributions ne s'emm… pas à fournir des bibliothèques, vu le bordel que ça met. Au hasard:
Au vu de ma faible expérience, ce qui fout le caca, c'est les bibliothèques peu utilisées : il n'y a pas de pression de la communauté pour intégrer les dernières versions dans les distributions, les mainteneurs ne sont pas forcément très dispo, etc. Du coup, on est dépendent des choix techniques des mainteneurs des paquets, choix qui ne sont pas forcément judicieux et qui peuvent ressembler à des rustines pas propres (par exemple, pour glew sous Ubuntu, la distrib reste sous 1.8 parce qu'il y a apparemment un bug quelque part avec la 1.9 et que la correction du bug n'a pas l'air d'être une priorité).
[^] # Re: Tu réponds déjà indirectement à ta question
Posté par shingo (site web personnel) . Évalué à 1.
C'est vrai que la statique est la meilleure solution. Cependant, j'ai décidé de proposer deux versions :
Un binaire i386 / x86_64 qui intègre le maximum de librairies afin de tourner sur n'importe quel distribution. Seul problème => GLIBC est requis dans sa version 2.17 vu que c'est ce j'utilise sur ma distribution. Du coup, seules les distributions "récentes" pourront le lancer sans se soucier des dépendances sauf pour Fedora 18, le mauvais élève qui reste encore avec son GLIBC 2.16.
Un paquet DEB / RPM qui embarque deux librairies dans son binaire. Pourquoi ? Car elles sont actuellement indisponibles sans compiler.
J'ai beau cherché dans tous les sens, j'ai même c'est nuit j'ai dû rêver d'un pamètre géniale qui permettait de préciser la version de chaque librairie qu'on voudrait utiliser lors de la compilation. Peut-être que cela existe-déjà ?
Je pense que c'est la meilleure solution pour le moment car beaucoup de personnes me demandent un binaire qui ne demandent pas d'installer d'autres librairies et encore moins de les compiler à la main. Ce que je peux tout à fait comprendre, car quand j'étais un grand novice sur Linux, je rebutais à compiler quoi que se soit. Même si on est sur les Linux, j'ai les ressentiments que les utilisateurs veulent quelques choses qui fonctionne sans manipuler ou ajouter de nouveaux éléments à leur installation du moins c'est surtout le cas pour les utilisateurs d'Ubuntu et Fedora.
[^] # Re: Tu réponds déjà indirectement à ta question
Posté par NeoX . Évalué à 2.
faut peut-etre regarder comment font les pilotes proprio qui recompile le module à chaque installation d'un nouveau noyau.
dans ton systeme d'installation, tu pourrais inclure :
- de telecharger les dependances si elles existent dans la distribution
- sinon de telecharger les sources de ces dependances, les compiler et les installer si la distribution ne fournit pas de paquet pour
[^] # Re: Tu réponds déjà indirectement à ta question
Posté par kadalka . Évalué à -6.
Télécharger : oui si on est prévenu.
Compiler : généralement non car cela bouffe du processeur et peut, comme mon cas, faire chauffer rapidement mon processeur.
[^] # Re: Tu réponds déjà indirectement à ta question
Posté par kadalka . Évalué à -5.
Enlever les S
C'est bien pour cela qu'il faut de temps en temps compiler en statique…
[^] # Re: Tu réponds déjà indirectement à ta question
Posté par kadalka . Évalué à -6.
Je n'ai jamais dit qu'il n'y a pas de problèmes…
J'ai dit que dans MON cas, il n'y a aucun soucis.
Mon propos est de répondre à la demande du monsieur de telle sorte qu'il puisse après se faire son idée…
Je présente mon opinion, mon expérience, et lui il choisi.
Je pense que lui il est un peu comme moi:
Il prend un logiciel qui lui plaît, il le compile perso, et comme il ne veut le faire qu'une seule fois, fais le choix de le rendre statique de manière à ce que ce soit disponible partout…
Très probablement, il se met à jour pour les bibliothèques et les problèmes liées à la sécurité…
Donc il recompile les éléments nécessaires…
Comme il le fait à titre personnel pour ses besoins propres, les problèmes de licences ne se posent plus.
Si par contre, il envisage de distribuer ses binaires, effectivement les licences incompatibles ne peuvent pas être mis en commun dans un même binaire, cela va de soi…
Votre expérience importe peu: ce qui importe c'est votre avis avec vos arguments. Du moins c'est ce qui m'intéresse personnellement. Les autres je ne sais pas.
A mon avis, les bibliothèques peu utilisées sont parfois un soucis, mais si çà marche pour le monsieur, je ne vois pas pourquoi il s'en priverait personnellement.
Exemple, Glibc ne convient pas forcément, mais je fais avec.
Là où je vois plus de soucis, c'est le cas de bibliothèques qui ont très peu de mainteneur et qui sont très utilisées.
Et là dessus nous sommes d'accord : un bug peut rester longtemps sans qu'on puisse rien faire…
(sauf à le modifier personnellement bien sûr)
# openSUSE Build Service : compilation pour Fedora, Debian, Ubuntu, SUSE Linux Enterprise
Posté par symoon . Évalué à 1.
https://build.opensuse.org/
J'ai cru comprendre que si ton projet est open source, tu peux t'enregistrer et te faire compiler des paquets pour plein de distribs.
Sinon, les sources doivent bien être disponibles quelque part..
PS: et pourquoi pas sur ton pc un chroot par distrib ?
[^] # Re: openSUSE Build Service : compilation pour Fedora, Debian, Ubuntu, SUSE Linux Enterprise
Posté par shingo (site web personnel) . Évalué à 1.
Se serait une bonne alternative, en effet. Je ne suis pas à l'aise encore avec le chroot, disons que pour installer ArchLinux pas de soucis je m'en sors correctement mais gérer plusieurs distributions en chroot ce n'est pas parlant d'autant plus que j'aimerais pouvoir tester en profondeur chaque distribution. Actuellement j'ai 5 distributions installées dans ma machine virtuelle. Ce qui nous donne :
Dans la journée je pense installer OpenSuse afin d'établir mes tests et créer un paquet pour la distribution.
Le fait d'avoir chaque distribution sous la main, me permet de tester le paquet et voir si le binaire se lance sans la moindre manipulation et sans l'ajout de librairies. C'est important pour moi car ça me permet d'être 100% que le binaire fonctionnera.
C'est vrai que c'est lourd et que ça demande du temps, mais pour le moment j'ai rien trouvé d'autres… à moins de récupérer un PC, de l'installer dans un coin et d'y installer toutes les distributions possibles :)
[^] # Re: openSUSE Build Service : compilation pour Fedora, Debian, Ubuntu, SUSE Linux Enterprise
Posté par NeoX . Évalué à 3.
la VM est une tres bonne solution
tu peux faire une seule VM avec toutes les distribs dedans
ou faire plein de VMs avec chacune une distrib en particulier.
perso j'utiliserais le 2e choix (1 Vm par distribution)
ainsi tu peux aisement reinstaller une distrib pour tester la derniere version, sans risquer de modifier les autres
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.