Créer un binaire portable.
Fermé
Atlantis
-
3 janv. 2013 à 21:42
mamiemando Messages postés 33134 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 mai 2024 - 5 janv. 2013 à 13:10
mamiemando Messages postés 33134 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 31 mai 2024 - 5 janv. 2013 à 13:10
A voir également:
- Créer un binaire portable.
- Créer un compte gmail - Guide
- Créer un compte google - Guide
- Créer un groupe whatsapp - Guide
- Créer un compte instagram - Guide
- Créer un organigramme - Guide
6 réponses
Bonjour,
Non, ce n'est pas possible. Toutes les distributions linux ne sont pas construites avec la même version du noyau ou des bibliothèques, sans parler des formats de paquets, et des petites différences dans la localisation des fichiers dans l'arborescence...
A partir du moment où un des éléments change de version (pour passer à une version supérieure non compatible), il faut recompiler le logiciel... c'est pour ça que contrairement à Windows on ne télécharge pas un exécutable n'importe où mais uniquement dans les dépôts de la distribution ce qui garantit d'avoir l'exécutable qui va bien avec la distribution.
Non, ce n'est pas possible. Toutes les distributions linux ne sont pas construites avec la même version du noyau ou des bibliothèques, sans parler des formats de paquets, et des petites différences dans la localisation des fichiers dans l'arborescence...
A partir du moment où un des éléments change de version (pour passer à une version supérieure non compatible), il faut recompiler le logiciel... c'est pour ça que contrairement à Windows on ne télécharge pas un exécutable n'importe où mais uniquement dans les dépôts de la distribution ce qui garantit d'avoir l'exécutable qui va bien avec la distribution.
mamiemando
Messages postés
33134
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
31 mai 2024
7 756
4 janv. 2013 à 00:38
4 janv. 2013 à 00:38
Ça dépend de quelles librairies dépend ton programme. Si on parle d'une application (exécutable...) et non d'un module (.ko) le noyau n'a pas d'impact. Le gestionnaire de paquets n'a pas d'impact non plus sur la portabilité ou non d'un programme.
Ceci dit, jns55 a raison, normalement on est sensé s'appuyer sur les paquets existants, donc en soit produire un exécutable standalone n'est généralement pas une très bonne idée (voir ci dessous les inconvénients).
Si on revient à ton problème, en gros l'idée c'est de le compiler avec des librairies statiques (.a) pour embarquer la librairie dans l'exécutable au lieu de la charger dynamiquement (.so). Voir notamment l'option "-static" (pour faire du static linking).
https://stackoverflow.com/questions/725472/static-link-of-shared-library-function-in-gcc
Tu peux voir à quelles librairies un binaire est lié avec la commande ldd.
Exemple :
De manière générale ce n'est pas une très bonne idée, car ça veut dire que l'exécutable ne bénéficiera pas des évolutions des librairies dont il dépend. En gros c'est toute la question entre choisir de lier (linker) son programme avec des librairies statiques ou dynamiques.
- Supposons que je linke mon programme avec libtoto.so qui pointe sur libtoto.so.3 et que libtoto.so.4 sorte, alors libtoto.so pointera par la suite sur libtoto.so.4. Sans avoir rien à recompiler mon programme bénéficiera implicitement des évolutions de libtoto. C'est la raison pour laquelle on privilégie généralement cette approche. Chez l'utilisateur final, la présence de libtoto.so sera garantie soit par le gestionnaire de paquets (si on fait une installation via le gestionnaire de paquets), soit vérifiée par ./configure (si on fait une installation à partir de sources).
http://www.mistra.fr/tutoriel-linux-gestionnaire-de-paquets.html
https://fr.wikipedia.org/wiki/Autotools
- Si au contraire, je linke mon programme avec libtoto.a, alors le contenu de libtoto.a est "copié" dans l'exécutable. L'utilisateur final n'a donc pas besoin d'avoir libtoto installée sur sa machine mais il ne bénéficiera pas des évolution de libtoto puisque le programme fonctionnera toujours avec celle qu'il embarque. De plus comme le programme embarque son code machine + celui de libtoto (et des autres librairies auxquelles il est lié statiquement), il est aussi beaucoup plus volumineux !
C'est la raison pour laquelle les gens qui veulent s'affranchir de la distribution fournissent généralement les sources à compiler (typiquement stockées dans un archive .tar.gz). L'utilisateur final doit alors compiler par lui-même son programme, ce qui conduit à un programme beaucoup plus léger.
Pour plus de détails tu peux lire ceci :
http://www.mistra.fr/tutoriel-linux-compiler.html
Malheureusement compiler un programme n'est pas à la portée de tout le monde. De plus si le programme est très volumineux, ça peut être très long (essaye de compiler firefox par exemple, tu vas comprendre ta douleur :p). C'est la raison pour laquelle les responsables d'un programme fournissent souvent un paquet (par exemple un fichier .deb, un fichier .rpm). Ceci évite à l'utilisateur final d'une part d'avoir à le compiler et d'autre part de garantir que tout ce qui est nécessaire au fonctionnement du programme est installé.
Peut-être peux-tu nous préciser un peu plus ton besoin...
Bonne chance
Ceci dit, jns55 a raison, normalement on est sensé s'appuyer sur les paquets existants, donc en soit produire un exécutable standalone n'est généralement pas une très bonne idée (voir ci dessous les inconvénients).
Si on revient à ton problème, en gros l'idée c'est de le compiler avec des librairies statiques (.a) pour embarquer la librairie dans l'exécutable au lieu de la charger dynamiquement (.so). Voir notamment l'option "-static" (pour faire du static linking).
https://stackoverflow.com/questions/725472/static-link-of-shared-library-function-in-gcc
Tu peux voir à quelles librairies un binaire est lié avec la commande ldd.
Exemple :
(mando@silk) (~) $ ldd /bin/ls
linux-vdso.so.1 => (0x00007fffdae33000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f9fa3959000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9fa3751000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f9fa3547000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9fa31bd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9fa2fb9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9fa3b95000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9fa2d9c000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f9fa2b97000)
De manière générale ce n'est pas une très bonne idée, car ça veut dire que l'exécutable ne bénéficiera pas des évolutions des librairies dont il dépend. En gros c'est toute la question entre choisir de lier (linker) son programme avec des librairies statiques ou dynamiques.
- Supposons que je linke mon programme avec libtoto.so qui pointe sur libtoto.so.3 et que libtoto.so.4 sorte, alors libtoto.so pointera par la suite sur libtoto.so.4. Sans avoir rien à recompiler mon programme bénéficiera implicitement des évolutions de libtoto. C'est la raison pour laquelle on privilégie généralement cette approche. Chez l'utilisateur final, la présence de libtoto.so sera garantie soit par le gestionnaire de paquets (si on fait une installation via le gestionnaire de paquets), soit vérifiée par ./configure (si on fait une installation à partir de sources).
http://www.mistra.fr/tutoriel-linux-gestionnaire-de-paquets.html
https://fr.wikipedia.org/wiki/Autotools
- Si au contraire, je linke mon programme avec libtoto.a, alors le contenu de libtoto.a est "copié" dans l'exécutable. L'utilisateur final n'a donc pas besoin d'avoir libtoto installée sur sa machine mais il ne bénéficiera pas des évolution de libtoto puisque le programme fonctionnera toujours avec celle qu'il embarque. De plus comme le programme embarque son code machine + celui de libtoto (et des autres librairies auxquelles il est lié statiquement), il est aussi beaucoup plus volumineux !
C'est la raison pour laquelle les gens qui veulent s'affranchir de la distribution fournissent généralement les sources à compiler (typiquement stockées dans un archive .tar.gz). L'utilisateur final doit alors compiler par lui-même son programme, ce qui conduit à un programme beaucoup plus léger.
Pour plus de détails tu peux lire ceci :
http://www.mistra.fr/tutoriel-linux-compiler.html
Malheureusement compiler un programme n'est pas à la portée de tout le monde. De plus si le programme est très volumineux, ça peut être très long (essaye de compiler firefox par exemple, tu vas comprendre ta douleur :p). C'est la raison pour laquelle les responsables d'un programme fournissent souvent un paquet (par exemple un fichier .deb, un fichier .rpm). Ceci évite à l'utilisateur final d'une part d'avoir à le compiler et d'autre part de garantir que tout ce qui est nécessaire au fonctionnement du programme est installé.
Peut-être peux-tu nous préciser un peu plus ton besoin...
Bonne chance
Bonjour,
Merci pour vos réponses, ça m'a beaucoup aider à comprendre.
En fait mon besoin c'est que lorsqu'on est sur deux ordinateurs, l'un tournant sur Windows (avec internet) et l'autre avec Ubuntu 11.10 LiveCD (sans internet) c'est difficile de télécharger un programme avec TOUT ses dépendances... surtout lorsqu'il nous n'est pas donné de porter internet sur l'autre ordinateur temporairement pour plusieurs raisons... Le programme en question est DOSBox.
Cordialement
Atlantis.
Merci pour vos réponses, ça m'a beaucoup aider à comprendre.
En fait mon besoin c'est que lorsqu'on est sur deux ordinateurs, l'un tournant sur Windows (avec internet) et l'autre avec Ubuntu 11.10 LiveCD (sans internet) c'est difficile de télécharger un programme avec TOUT ses dépendances... surtout lorsqu'il nous n'est pas donné de porter internet sur l'autre ordinateur temporairement pour plusieurs raisons... Le programme en question est DOSBox.
Cordialement
Atlantis.
Une astuce pour récupérer toutes les dépendances d'un seul coup :
Ton ordinateur Windows a l'internet. Lance ton live-cd ubuntu sur cet ordinateur, tu dois avoir accès à l'internet au moins par l'intermédiaire du cable ethernet même si le wifi n'est pas opérationnel.
Ouvre un terminal puis un petit coup de :
ce qui aura pour effet d'installer dosbox et toutes ses dépendances dans ta session live-cd d'ubuntu.
Et maintenant, il ne te reste plus qu'à récupérer le paquet dosbox et toutes ses dépendances dans le cache : tu ouvres l'explorateur de fichiers dans le dossier /var/cache/apt/archives, tu copies tous les paquets présents et tu les sauvegardes sur un support externe, tu les auras sous la main lorsque tu en auras besoin pour l'installer sur ton pc sans internet.
Et le tour est joué...
Ton ordinateur Windows a l'internet. Lance ton live-cd ubuntu sur cet ordinateur, tu dois avoir accès à l'internet au moins par l'intermédiaire du cable ethernet même si le wifi n'est pas opérationnel.
Ouvre un terminal puis un petit coup de :
sudo apt-get install dosbox
ce qui aura pour effet d'installer dosbox et toutes ses dépendances dans ta session live-cd d'ubuntu.
Et maintenant, il ne te reste plus qu'à récupérer le paquet dosbox et toutes ses dépendances dans le cache : tu ouvres l'explorateur de fichiers dans le dossier /var/cache/apt/archives, tu copies tous les paquets présents et tu les sauvegardes sur un support externe, tu les auras sous la main lorsque tu en auras besoin pour l'installer sur ton pc sans internet.
Et le tour est joué...
mamiemando
Messages postés
33134
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
31 mai 2024
7 756
Modifié par mamiemando le 5/01/2013 à 13:10
Modifié par mamiemando le 5/01/2013 à 13:10
Si tu prends une ubuntu serveur (ie une ubuntu sans interface graphique) ça peut le faire et du moment que c'est la même version d'ubuntu (même numéro de version (par exemple 11.10) et même architecture (par exemple i386)), ce sont les mêmes paquets.
Tu peux demander à dpkg d'ajouter des architectures si besoin.
Exemple :
Ensuite tu peux vider le cache (/var/cache/apt/archives) :
... et récupérer comme le suggérait jns55 le contenu de /var/cache/apt/archives.
Bonne chance
Tu peux demander à dpkg d'ajouter des architectures si besoin.
Exemple :
dpkg --add-architecture i386
Ensuite tu peux vider le cache (/var/cache/apt/archives) :
sudo apt-get clean sudo apt-get update sudo apt-get install -a i386 -d install dosbox
... et récupérer comme le suggérait jns55 le contenu de /var/cache/apt/archives.
Bonne chance
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Merci pour vos précieux conseils, mais en soit je ne tiens pas à mettre mes programmes à jour dans ce cas si. Donc je vais regarder ça plus en profondeur.
mamiemando
Messages postés
33134
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
31 mai 2024
7 756
5 janv. 2013 à 13:10
5 janv. 2013 à 13:10
Ce que je t'ai indiqué ne déclenche pas une mise à jour car il n'y a pas de "sudo apt-get upgrade". "apt-get update" ne fait que réindexer la liste des paquets fournis par les miroirs.
Bonjour,
Sinon, il te reste la solution de faire la manipulation avec le live-cd sur le PC d'une connaissance. Je sais, c'est pas forcément évident de faire admettre à la personne en question que son PC ne risque rien, qu'on ne touche pas au disque dur... De plus si par malheur son PC se met à déconner dans les jours ou les semaines qui suivent, le responsable sera tout trouvé.
Sinon, il te reste la solution de faire la manipulation avec le live-cd sur le PC d'une connaissance. Je sais, c'est pas forcément évident de faire admettre à la personne en question que son PC ne risque rien, qu'on ne touche pas au disque dur... De plus si par malheur son PC se met à déconner dans les jours ou les semaines qui suivent, le responsable sera tout trouvé.
