Forum Programmation.c++ Compiler en statique, est-ce vraiment un problème ?

Posté par (page perso) . Licence CC by-sa
Tags : aucun
2
28
mai
2013

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 (page perso) . É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…

    https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

    • [^] # Re: bah...

      Posté par (page perso) . É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 . É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 . É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.

    • A part dans ton wrapper tu n'auras pas d'adaption de ton code à réaliser.
    • Tu deviens indépendant de la librairie à utiliser.
    • Tu peux activer ou désactiver les fonctions en fonction de la présence des versions de la bibliothèque prise en charge par ton wrapper.

    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 . É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 . É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 . É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 . É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 . É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:

      • Les bugs et mises à jour de sécurité dans les bibliothèques peuvent être corrigés sans toucher le logiciel
      • L'utilisateur ne télécharge que ce dont il a besoin
      • La RAM est partagée entre toutes les applis qui utilisent les mêmes bibliothèques
      • Ca oblige à ce que le code suive une certaine discipline
      • Ca facilite la lisibilité des licences (pas besoin par exemple de publier un code sous GPL accompagné du code des bibliothèques sous d'autres licences).
      • Ca dissuade de faire trop de dépendances à des trucs pas forcément utiles et ça fait réfléchir un peu sur la légitimité de s'embarquer à long terme avec un projet dont on ne connait pas grand chose.

      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 (page perso) . É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 . É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 . Évalué à -6.

            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

            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 . Évalué à -5.

          quelqueS choseS

          Enlever les S

          " Même si on est sur les Linux, j'ai les ressentiments que les utilisateurs veulent quelque chose 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 " (…)

          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 . Évalué à -6.

        " 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 " (…)

        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…

        " Au vu de ma faible expérience, ce qui fout le caca, c'est les bibliothèques peu utilisées " (…)

        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 . É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 (page perso) . É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 :

      • Fedora F18 i686
      • Fedora F18 x86_x64
      • Fedora F19 x86_64
      • Xubuntu 13 i386
      • Xubuntu 13 adm64

      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 :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.