Le problème c'est que sous linux quand je lance l'executable (sur un ordi où j'ai pas installé la SDL), par exemple depuis le terminal avec ./executable ça me met ça :
./executable: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory
Je comprend ce message, c'est un peu le même que sous Windows quand il y a des .dll qui manquent.
Du coup j'aimerais savoir où est ce que je peux trouver ce fichier libSDL-1.2.so.0 s'il est sur mon disque dur ...
Merci d'avance.
EDIT : j'ai trouvé sur le site de la SDL ce fichier .so, mais j'ai beau le mettre à côté de l'executable j'ai toujours la même erreur...
normalement une distro linux possède un gestionnaire de paquets. Tu distribues ton jeu comme un paquet qui liste comme dépendance la SDL1.2 et ceux qui vont installer le jeu vont aussi se faire installer la SDL1.2 si nécessaire.
Tu peux aussi comiler ton exécutable en le liant avec la bibliothèque statique de la SDL1.2 pour ne plus avoir ce genre de dépendance.
First solve the problem. Then, write the code. ~ John Johnson
Donc si j'ai bien compris je dois distribuer mon jeu comme un paquet qui liste comme dépendance la SDL1.2 et ceux qui vont installer le jeu vont aussi se faire installer la SDL1.2 si nécessaire.
Je viens m'incruster parce que j'ai découvert ce problème il y a plusieurs mois à propos de mes petits programmes graphiques écrits avec la bibliothèque Allegro. Quand j'ai découvert ce problème, je m'étais dit : un de ces jours, il faudra que je me renseigne pour comment le résoudre.
Du coup le jour est arrivé : comment on fait pour compiler avec la version statique ?
Bon, comme vous m'avez donné un point de départ, j'ai cherché dans le man de gcc (qui fait 800 Ko !!!) et j'ai trouvé l'option -static . Il est indiqué que « On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect. » Étant nul en anglais, je ne comprends pas bien : ça veut dire que ça empêche qu'il fasse une édition de lien dynamique ? Donc c'est forcément statique ? (Expliquer un truc en utilisant une négation n'est pas très clair. Ça sert à quoi, la clé de contact ? Ça empêche que la voiture ne démarre pas...)
Bref, Major_zero et moi, on a juste à ajouter -static dans les options de compilation ?
Pour lier avec une bibliothèque statique il faut en premier lieu disposer de la bibliothèque statique, sinon ce n'est pas possible. Il faut évidemment construire le projet avec les mêmes options que celles utilisées pour construire la bibliothèque statique. Ensuite il s'agit simplement de la lister en dépendance (avec make ou autre) et lors de l'édition de liens la rajouter directement comme n'importe quel autre fichier objet (je parle de linux, gcc, bibliothèque statique type .a = pas de libtool).
En cherchant un tout petit peu sur le net on trouve SDL2 static linking. Le lien explique que ce n'est pas possible pour des raisons de droits avec la SDL1.2 mais que c'est possible avec la SDL2. Les avantages d'une édition des liens avec une bibliothèque statique :
on ne dépend pas de la version installée ni même si elle est installée
fine tuning de la bibliothèque
avec les compilos/linker modernes il y a une phase LTO (link time optimisation) qui peut parfois améliorer les perfs
...
Les inconvénients :
pas de partage de la bibliothèque en mémoire, 3 programmes liés statiquement avec la même bibliothèque donneront trois fois la même version en mémoire
si une faille de sécurité ou un bug est découvert dans la bibliothèque il faudra tout recompiler et tout redistribuer
la taille de l'exécutable est plus grande
...
Edit: pour compléter un peu la réponse. Je teste l'outil meson pour remplacer les autotools (une plaie). Il propose par défaut la notion de subproject. Il s'agit simplement d'un lien vers une version de bibliothèque, puis à la demande ou si la machine sur laquelle on compile ne dispose pas d'une ressources listée en subproject, il se charge de la télécharger/compiler/intégrer. C'est un outil en cours de développement mais relativement avancé. Cela permet d'avoir un build cohérent. Pour créer les paquets ou autre exe d'install c'est une autre histoire.
- Edité par PicoDev 20 février 2017 à 17:03:03
First solve the problem. Then, write the code. ~ John Johnson
Il y a aussi une phase de résolution de nom. Il faudra vérifier dans la doc du compilo les algos de chemins de recherche/résolution de nom de la commande -l.
First solve the problem. Then, write the code. ~ John Johnson
Au fait, est-ce que ces problèmes de version statique ou dynamique se posent aussi avec la bibliothèque math ? (Après tout, il faut la compiler avec -lm donc ça a l'air de jouer un rôle identique à la SDL ou Allegro.)
bah la libc et, si elle existe, la libm sont des composants essentiels de l'OS (hors windows et encore ...). Pour d'obscures et antiques raisons la partie «math» de la bibliothèque C standard est, sur certains OS, proposée comme une bibliothèque séparée de la libc. Par défaut gcc liera un programme avec la libc dynamique du système sauf si tu lui demandes d'en utiliser une autre ou de ne pas l'utiliser du tout.
Pour lier avec des versions statiques il suffit d'en disposer et de bien le préciser au compilo.
First solve the problem. Then, write the code. ~ John Johnson
Si je veux compiler avec la bibliothèque mathématique standard, je dois le préciser :
gcc main.c -o main -lm
Sans -lm ça ne marche pas. C'était le cas sous Windows 7 avec MinGW et c'est le cas sous mon Linux actuel avec GCC.
Si je veux compiler avec la bibliothèque Allegro, je dois faire quelque chose de parfaitement similaire :
gcc main.c -o main -lalleg
Je sais, parce que j'ai essayé, que mes programmes compilés avec Allegro ne marchent pas sur une configuration où Allegro n'a pas été installé, et vous avez bien expliqué que c'est parce que, par défaut, la compilation est dynamique. Pour les programmes utilisant la libm, j'imagine que ça causerait le même problème, sauf que tout le monde a la libm sur sa machine (en tout cas sous Linux). Quoique ? Il me semble que par défaut, sous Ubuntu, on n'a pas les outils de développement (j'ai un vague souvenir d'avoir dû les ajouter au tout début).
Quoiqu'il en soit, j'avoue que je n'ai pas compris grand chose aux dernière réponses, mais peut-être qu'elles ne concernaient que la SDL ? Je pensais qu'il fallait juste ajouter -static comme option de compilation, donc en fait non ? J'ai vérifié, j'ai des liballeg.so mais je n'ai pas de liballeg.a, donc ça veut dire que je ne peux pas faire de compilation statique, c'est bien ça ? Donc si je veux prêter mon programme à quelqu'un qui utilse Linux mais n'a pas installé Allegro, il faut faire un paquet. Tout ça pour un petit programme de 25 lignes. Prise de tête. Pas le courage d'aller plus loin...
Si je veux compiler avec la bibliothèque mathématique standard, je dois le préciser :
gcc main.c -o main -lm
Sans -lm ça ne marche pas. C'était le cas sous Windows 7 avec MinGW et c'est le cas sous mon Linux actuel avec GCC.
Les raisons sont (du moins pour moi) assez obscures et certainement (toujours pour moi) obsolètes. Quand on cherche le pourquoi du comment on trouve des explications comme «du temps où il n'y avait pas de copro dédié il y avait une version software et hardware», «cela permet facilement d'implémenter des versions différentes (?) pour les matheux», «sur les anciennes plateformes cela réduisait le temps de compilation/chargement/…». Enfin bref, tout comme nous possédons une queue vestigiale, on a aussi la libm «vestigiale» ^_^.
robun a écrit:
Si je veux compiler avec la bibliothèque Allegro, je dois faire quelque chose de parfaitement similaire :
gcc main.c -o main -lalleg
Je sais, parce que j'ai essayé, que mes programmes compilés avec Allegro ne marchent pas sur une configuration où Allegro n'a pas été installé, et vous avez bien expliqué que c'est parce que, par défaut, la compilation est dynamique. Pour les programmes utilisant la libm, j'imagine que ça causerait le même problème, sauf que tout le monde a la libm sur sa machine (en tout cas sous Linux). Quoique ? Il me semble que par défaut, sous Ubuntu, on n'a pas les outils de développement (j'ai un vague souvenir d'avoir dû les ajouter au tout début).
La commande que tu montres est simple, elle demande au linker de chercher une bibliothèque nommée alleg. Ensuite il faut regarder attentivement la doc du compilo pour savoir ce qu'il cherche et où. A priori, gcc sous linux va lancer le linker (ld ou gold) qui à partir d'un -lalleg va chercher là où tu lui dis de chercher (via -L) et dans des endroits préconfigurés (/lib et autres) un fichier nommé liballeg.so. Le -static va préférer une version statique si elle est trouvée (liballeg.a). Mais bon, ça va vraiment dépendre des compilos.
Tu peux voir les paquets de bibliothèques comme étant fournies en plusieurs versions. Une version runtime qui ne contient que la bibliothèque, la version dev qui contient les bibliothèques et les headers, les versions profilées ou de debug peuvent aussi exister. Tu n'as pas besoin pour utiliser une bibliothèque d'avoir la version dèv avec les headers et autres outils, la bibliothèque «toute seule» va suffire (en gros).
Ce sera le loader qui va se charger de charger l'image de l'exécutable et de trouver les bibliothèques dynamiques que l'exécutable réclame.
robun a écrit:
Quoiqu'il en soit, j'avoue que je n'ai pas compris grand chose aux dernière réponses, mais peut-être qu'elles ne concernaient que la SDL ? Je pensais qu'il fallait juste ajouter -static comme option de compilation, donc en fait non ? J'ai vérifié, j'ai des liballeg.so mais je n'ai pas de liballeg.a, donc ça veut dire que je ne peux pas faire de compilation statique, c'est bien ça ? Donc si je veux prêter mon programme à quelqu'un qui utilse Linux mais n'a pas installé Allegro, il faut faire un paquet. Tout ça pour un petit programme de 25 lignes. Prise de tête. Pas le courage d'aller plus loin...
Si tu n'as pas la version statique de la bibliothèque tu ne pourras pas la lier ... donc non si tu n'as pas liballeg.a ...
Si tu utilises une programme qui a besoin d'une bibliothèque dynamique alors il faut que cette bibliothèque dynamique soit présente. Tu n'es pas obligé de faire un paquet, tu peux simplement demander à ton utilisateur d'installer les bibliothèques nécessaire en précisant qu'il faut faire un «apt get machin» par exemple.
Tu peux aussi, à défaut de lier statiquement, utiliser un LD_LIBRARY_PATH qui indique où chercher les bibliothèques dynamiques au moment du chargement ... mais ce n'est pas recommandé du tout.
First solve the problem. Then, write the code. ~ John Johnson
Pour les programmes utilisant la libm, j'imagine que ça causerait le même problème, sauf que tout le monde a la libm sur sa machine (en tout cas sous Linux). Quoique ? Il me semble que par défaut, sous Ubuntu, on n'a pas les outils de développement.
En général on n'a pas les outils de développement, mais la libm est tout ce qu'il y a de plus productif, donc on l'a.
Suite à un autre sujet, j'ai remarqué que les fonctions math étaient directement dans la version statique de la libc musl. Du coup en consultant la faq :
Why is libm.a empty?
On musl, the entire standard library is included in a single library file — libc.a for static linking, and libc.so for dynamic linking. This significantly improves the efficiency of dynamic linking, and avoids all sorts of symbol interposition bugs that arise when you split the libraries up — bugs which have plagued glibc for more than a decade.
Why not just omit libm.a, libpthread.a, etc. entirely? POSIX says -lm, -lpthread, etc. are valid options to the compiler and conforming applications must use these options when they need the corresponding functionality, and the easiest way to comply with that requirement (and avoid breaking applications) is with empty .a files by those names.
comme quoi, la libm c'est vraiment un vieux truc qu'on traîne.
- Edité par PicoDev 21 février 2017 à 19:53:21
First solve the problem. Then, write the code. ~ John Johnson
Voila j'ai réussi à résoudre mon problème de base : J'ai créé un .deb qui installe la sdl (et ses extensions) ainsi que la FMOD ex (j'ai mit comme dépendance (dans le fichier DEBIAN/control) la SDL et ces extensions, et j'ai créé un dossier usr/lib/ où j'ai mit les .so de la FMOD ex (car la FMOD ex n'est pas sur les dépots officels)).
Seulment ce .deb n'installe pas l’exécutable. Du coup j'ai créé un .tar.gz avec dedans le .deb et à côté l’exécutable sur lequel on clique après avoir installer le .deb
Est-ce une bonne méthode d'installation ? Merci d'avance.
Dans l'idéal, j'ai juste envie de télécharger un .deb, l'installer et tout roule sans avoir besoin de faire quoi que ce soit d'autre.
Du coup je devrais inclure l'executable par exemple dans ~/Bureau, comme ça quand ça installe le .deb l'utilisateur aura une icone sur son Bureau ?
Il y a plusieurs choses différentes :
installation de ton paquet sur le système les bon fichiers aux bons endroits (les exe dans /usr/local/bin, les autres fichiers dans /usr/local/share/<nom du programme>) au premier lancement tu peux créer un répertoire par user dans son home folder ...
création de shortcuts suivant le ou les desktops (j'imagine que ce n'est pas pareil pour kde/gnome/xfce/enlightenment) le mettre dans ~/Bureau n'est certainement pas une bonne idée il faut se plier aux exigences de chaque desktop
First solve the problem. Then, write the code. ~ John Johnson
D'accord donc si j'ai bien compris je dois mettre l’exécutable dans /usr/local/bin/ mais l'utilisateur sera-t-il que mon programme est installé dans ce dossier ?
De plus mon exécutable requiert des ressources que je stocke dans un dossier "data" à côté de l’exécutable. Du coup si je met le dossier data dans /usr/local/bin ça risque pas de rentrer en conflit avec d'autres programmes ?
Justement, tu dois splitter les répertoires d'installation. Je donnais /usr/local comme exemple ...
Un logiciel est composé de plusieurs parties, les exécutables, les bibliothèques, les données autres, la doc, … chaque partie ira dans un répertoire particulier suivant la norme utilisée par la distro → Filesystem Hierarchie Standard.
Pour les desktop env il y a aussi des standards comme XDG.
First solve the problem. Then, write the code. ~ John Johnson
Problème .so sous Linux
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Mon jeu multi online gratuit : https://gamejolt.com/games/space-war/482884
Mon jeu multi online gratuit : https://gamejolt.com/games/space-war/482884
Mon jeu multi online gratuit : https://gamejolt.com/games/space-war/482884
Mon jeu multi online gratuit : https://gamejolt.com/games/space-war/482884
Mon jeu multi online gratuit : https://gamejolt.com/games/space-war/482884
Mon jeu multi online gratuit : https://gamejolt.com/games/space-war/482884