Installer un logiciel à partir des sources
De Wiki de la communauté Mandriva.
MLO (http://www.mandrivalinux-online.org) est un site d'aide dédié aux débutants sous Mandriva Linux
Théorie
Les bases de la compilation
Un programme s'écrit dans un langage de programmation. Certains langages, en particulier ceux qu'on appelle des « langages de script », permettent de lancer directement des programmes écrits dans ces langages de programmation. Des exemples bien connus de ce genre de langages sont Perl, Python, Tcl/Tk, ainsi que le shell Bash. De tels programmes sont exécutés grâce à un « interpréteur », un logiciel qui sert d'interprète, qui traduit au fur et à mesure, à la volée, les commandes successives du programme pour le système. Il est à noter que pour de tels programmes, écrits dans un langage « interprété », la traduction/interprétation en langage machine a lieu lors de chaque exécution du programme, elle n'est pas « stockée » dans un fichier permanent.
D'autres langages, comme le C ou le C++, exigent au contraire que le programme écrit dans ce langage soit converti, « compilé », en un fichier « binaire » en langage machine, pour pouvoir être exécuté. La compilation a lieu en principe une fois et ensuite, c'est le fichier binaire en langage machine, stocké sur le système ou en un lieu accessible au système, qui sera exécuté, et non sa « source » en C, ou C++ etc.
Chacune de ces deux techniques a ses avantages et ses inconvénients : les programmes interprétés demandent moins de temps de développement, tandis que les programmes compilés n'ont pas besoin d'interpréteur et sont donc exécutés plus rapidement, ils sont en général plus appropriés pour l'exécution de tâches complexes.
La compilation traduit un texte lisible par l'homme, la « source », en un fichier lisible par la machine, le fichier « binaire ». La première chose dont on a besoin pour compiler est un compilateur. Sous Linux, le compilateur est gcc pour les programmes écrits en C (qui constituent la majorité), et 'g++' (autrement dit gcc-c++) pour les programmes écrits en C++.
Les programmes complexes peuvent être formés d'un grand nombre de fichiers source. Afin de rendre la compilation plus facile, les instructions de compilation sont souvent énumérées dans un fichier particulier appelé le Makefile. Pour utiliser ce fichier on a besoin du programme make. make lit (anglais parses) le Makefile et fournit ainsi au compilateur les options appropriées. Vous pouvez modifier ces options (comme par exemple l'endroit où les fichiers compilés seront installés) en éditant le fichier Makefile.
Quand il écrit des programmes, le programmeur, n'écrit pas en fait la totalité de ces programmes. Il utilise des « bibliothèques » qui lui fournissent un ensemble de fonctions déjà disponibles communément utilisées. Le programmeur introduit seulement un « lien » dans le fichier source, lien qui renvoie à une certaine bibliothèque ou à une fonction de cette bibliothèque. Le binaire compilé aura besoin de cette bibliothèque pour être exécuté.
Et en outre, quand vous compilerez ce programme, le compilateur devra pouvoir accéder à certains fichiers source appelés « fichiers d'en-tête » (anglais headers) qui font en quelque sorte le lien entre le programme proprement dit et les bibliothèques. Il aura donc aussi besoin de ces fichiers.
Puisque vous n'avez besoin de ces fichiers d'en-tête que pour la compilation, il pourrait être raisonnable de subdiviser tout paquetage RPM de bibliothèque en deux : un paquetage qui contient les fichiers nécessaires pour exécuter un programme et un paquetage qui contient les fichiers nécessaires pour compiler un programmme. Et c'est devenu là une pratique courante des diverses distributions : un paquetage contient la bibliothèque elle-même (c'est la « version d'exécution ») et un second paquetage, marqué comme -devel- (pour development), contient les fichiers d'en-tête.
Ainsi donc vous aurez aussi besoin des paquetages qui contiennent les fichiers d'en-tête des bibliothèques dont dépend le programme à compiler. Pour plus de détails sur les bibliothèques vous pourrez consulter l'excellent article de Wikipédia : Bibliothèque logicielle
.
Et maintenant comment savoir de quelles bibliothèques un programme a besoin. La façon « la plus simple » devrait être d'essayer de compiler les sources. Le processus de compilation réclamera son dû s'il ne peut pas trouver une bibliothèque dont il a besoin...
La seconde possibilité consiste en un examen du fichier Makefile lui-même. Au début du fichier on trouve une liste qui commence par LIBS =, et qui énumère toutes les bibliothèques requises. Notez qu'elles sont notées en abrégé: :-lX11 par exemple est un raccourci pour le nom de fichier libX11.so. Faites un
pour déterminer si ce fichier est installé sur votre système.
Un troisième mécanisme est le script configure, qu'un programmeur peut créer en utilisant le programme autoconf ou autoscan. Pour créer le script configure, autoconf utilise le fichier configure.in et vérifie si toutes les bibliothèques et les fonctions nécessaires sont disponibles sur votre système. Si ce n'est pas le cas, il échouera et vous dira ce qui ne va pas. Lancez donc la commande :
Décompacter les archives
Les sources sont généralement distribuées sous forme d'archives compactées. C'est là une manière de procéder tout à fait naturelle étant donné, d'une part, qu'elles contiennent généralement plus d'un fichier qu'il peut donc être pratique de réunir en un seul fichier d'archive et étant donné d'autre part que les sources sont des fichiers texte et que le compactage fonctionne particulièrement bien sur les fichiers texte.
Sous UNIX, de telles archives sont créées et compactées par deux programmes différents: l'un, le programme tar, qui réunit tous les fichiers en un seul fichier d'archive et l'autre qui effectue le compactage (on dit aussi « la compression »). On utilise pour la compression, selon les cas, le programme gzip ou le programme bzip2. Par convention les fichiers d'archive qui ont été compactés à l'aide du logiciel gzip ont un nom qui se termine par tar.gz ou par tgz, tandis que les noms des fichiers d'archive qui ont été compactés à l'aide du logiciel bzip2 se terminent par tar.bz2 ou tbz2. Ces archives sont appelées familièrement des tarball (jeu de mot sur l'anglais tar qui désigne à la fois le programme d'archivage et ... le goudron; tarball c'est une balle de goudron, on joue sur l'idée que dans une archive tous les fichiers sont comme collés les uns aux autres par du goudron).
Pour décompacter des archives, on peut soit utiliser un gestionnaire graphique d'archives comme l'Archiveur de KDE ou 'guiTAR' de GNOME. Dans KDE et dans GNOME, ils devraient démarrer automatiquement lorsque vous (double)-cliquerez sur le fichier d'archive dans le gestionnaire de fichier approprié.
En ligne de commande vous taperez :
La première option ('x') signifie 'extraire'. Pour créer des archives, vous devez la remplacer par l'option 'c', et pour simplement afficher la liste du contenu de l'archive vous la remplacerez par l'option 't'. La seconde option ('v'), qui n'est pas obligatoire, impose le mode « disert » (elle oblige 'tar' à afficher différents messages d'information utiles) et le 'f' annonce à 'tar' que ce qui suit est un nom de fichier (et non l'entrée ou la sortie standard).
Pendant longtemps, il a été indispensable pour traiter une archive dont l'extension est '.gz' ou '.tgz', archive qui a été compactée avec le logiciel 'gzip', de fournir à 'tar' l'option 'z' et pour décompacter une archive compactée avec le logiciel bzip2 et dotée de l'extension .bz ou .bz2 de fournir l'option 'j'. C'est devenu maintenant inutile, depuis la version 1.15 de tar de décembre 2004. Eh oui ! la ligne de commande s'allège au fil du temps !
De "pures" archives 'bzip2' ou même 'zip' sont assez rares dans le monde de Linux. Elles peuvent être décompactées à l'aide des commandes
ou
(cette dernière commande marche aussi avec les archives auto-extractibles '.exe').
Des fichiers importants à lire
La plupart des archives de sources contiennent des fichiers appelés README et INSTALL. Ce sont des commentaires écrits par le programmeur, qui portent sur le programme lui-même et la façon de le compiler et contiennent toute sorte d'indications utiles... Il va sans dire que vous devriez lire ces fichiers ;-), à moins que le fichier INSTALL ne commence par: 'These are generic instructions' (= Ce qui suit est un ensemble d'instructions génériques...), auquel cas le programmeur ne s'est pas préoccupé de remplacer le fichier engendré automatiquement par autoconf par quelque chose de plus spécifique et de plus utile.
Comme tout autre fichier d'archive ces deux fichiers peuvent être ouverts par tout programme capable d'afficher le contenu d'un fichier texte.
Les paquetages indispensables
Voici une liste de paquetages dont vous aurez besoin pour compiler. Commencez donc par vérifier s'ils sont bien installés sur votre système, en lançant la commande rpm -q nom_de_paquetage.
Le compilateur
* gcc * glibc-devel * gcc-c++ * libstdc++-devel
Les outils système
* make
Les bibliothèques les plus courantes
Certaines bibliothèques sont utilisées par de nombreuses applications. Installer les versions de développement de ces bibliothèques vous permettra dans la plupart des cas de compiler sans rencontrer d'erreur due à l'absence de bibliothèques. Les versions de développement de bibliothèques énumérées ci-dessous sont les plus 'populaires' dans le monde des programmeurs.
- libgtk+-devel, libglib-devel (ensemble d'objets graphiques interactifs très courants (les « widgets »))
- libgr-devel, libungif-devel, libjpeg-devel, libpng-devel, libtiff-devel, libxpm-devel (formats d'images)
- libtermcap-devel, libncurses-devel (pour les applications qui utilisent la console)
- libxorg-devel (pour toutes les applications graphiques)
- zlib-devel (bibliothèque pour la compression)
Si vous compilez des programmes pour GNOME ou KDE, il vous faudra les versions '-devel-' de leurs bibliothèques. Pour KDE, vous aurez aussi besoin de 'libqt-devel'.
Deux choses sont à noter en ce qui concerne les noms de paquetages de bibliothèques :
- D'anciens paquetages de bibliothèques de 'Mandrake Linux' peuvent ne pas contenir le préfixe 'lib', par exemple 'libgtk+-devel' était autrefois 'gtk+-devel'.
- Le nom de certains paquetages de bibliothèques peut contenir un numéro de version, par exemple, le véritable nom de 'libpng-devel' pourrait être 'libpng3-devel'. Ce n'est pas très important mais c'est tout de même bon à savoir pour s'y retrouver !
Et maintenant vous voilà fin prêt pour la compilation !
En pratique
Lancer configure
A l'heure actuelle, la plupart des sources à compiler s'accompagnent d'un script configure, qui vérifie si le programme pourra être compilé sur le système en l'état. La commande :
exécutée dans le répertoire source, affichera une liste des options disponibles pour la commande configure. Ne vous inquiétez pas, les valeurs par défaut devraient convenir dans la plupart des cas.
Toutefois, il y a une option à laquelle il faudra porter une attention toute particulière : il s'agit de --prefix=, qui se trouve au début de la liste des options. C'est à l'endroit indiqué que seront compilés et installés les programmes et leurs bibliothèques. Cette valeur est souvent renseignée avec /usr ou /usr/local. Les deux valeurs sont correctes, mais je préfère, pour ma part, installer les programmes que je compile moi-même dans le répertoire /opt, afin de garder un œil dessus, ce choix est particulièrement bienvenu si chez vous /opt est sur une partition distincte de la partition système /. Vous pourrez alors conserver le contenu de /opt et donc des applications personnelles que vous avez compilées vous-même après une mise à jour ou une réinstallation du système. Si vous optez pour cette solution vous lancerez donc une commande :
Certains programmes KDE considèrent que vous disposez d'un répertoire /opt/kde et l'utilisent comme répertoire d'installation par défaut. Si votre distribution Mandriva installe, quant à elle, les fichiers KDE sous /usr, vous devrez changer cette valeur en lançant la commande configure, comme ci-dessous :
Pourquoi ./configure au lieu de configure?
Parce qu'un répertoire récemment créé contenant le code source du programme à compiler ne fait habituellement pas (déjà) parti de votre path shell. En conséquence, si vous saisissez configure, le shell répondra :
Vous devez donc spécifier au shell que vous souhaitez exécuter une commande qui est dans le répertoire de travail courant. Ce qui se fait en ajoutant le préfixe ./ à la commande.
Pour en savoir davantage sur la configuration des chemins (paths) pour les exécutables sous Linux cliquez ici.
Notez qu'il n'est ni nécessaire ni recommandé de lancer le script configure en tant que root.
Mais que manque-t-il donc ?
Et voilà maintenant que le programme configure s'exécute et qu'il effectue certaines vérifications concernant votre système. Sa sortie s'affiche à la console et elle est aussi envoyée dans un nouveau fichier : config.log. configure s'arrête automatiquement s'il découvre une erreur qui interdirait la réussite de la compilation. Il affiche alors un message d'erreur et l'écrit dans config.log, ce peut être quelque chose comme, par exemple :
ce qui se traduit plus ou moins ainsi :
On dirait bien qu'il manque quelque chose, mais que peut donc être -lXt ? Eh bien sachez qu'il existe une convention selon laquelle -l représente lib ... .so. Ce qui fait défaut ici est donc le fichier libXt.so.
Il y a de bonnes chances que ce fichier de bibliothèque figure dans quelque -devel-.rpm que vous n'avez pas installé. Sous Mandriva, utilisez le Gestionnaire de logiciels (rpmdrake) pour chercher un paquetage contenant ce fichier ou bien utilisez urpmf et tapez urpmf fichier sur la ligne de commande.
Vous pouvez aussi vous placer dans le répertoire du CD qui contient les RPM (un répertoire de /mnt/cdrom/) et lancer cette commande :
(Remplacez, bien sûr, fichier par le nom du fichier que vous cherchez).
Vous pourrez constater qu'il appartient à 'XFree86-devel'. Installez donc ce RPM à l'aide d'une interface graphique ou de urpmi via la commande :
Et maintenant effacez le fichier config.cache du répertoire source et relancez configure. Recommencez tout cela jusqu'à ce que configure se termine sans erreur.
Si d'aventure vous ne trouvez pas de RPM qui contienne le fichier dont vous avez besoin et que la documentation jointe ne vous aide pas non plus, essayez d'entrer en contact avec l'auteur du logiciel. C'est lui qui sait ! Mais commencez par vérifier d'abord par vous-même plutôt deux fois qu'une !
Lancer make
Si l'exécution de configure a été couronnée de succès, il va falloir maintenant compiler réellement les sources à l'aide de :
Il ne devrait pas y avoir d'erreur à moins que le script configure n'en contienne lui-même (eh oui, un accident est toujours possible !).
Bien que les messages d'erreur de make puissent paraître un peu plus obscurs que ceux de configure, la procédure, en cas d'erreur est très voisine de celle que nous avions décrite plus haut.
Si quelque chose ne va pas vous obtiendrez généralement quelque chose comme :
ou comme :
Dans le premier cas, installez le RPM qui contient le fichier manquant. Un message d'erreur qui contient un nom de fonction (function name) implique généralement que le programme a besoin d'une version de bibliothèque plus récente ou plus ancienne que celle que vous avez installée. Voyez si vous pouvez trouver une mise à jour, ou au contraire une version ancienne, et installez-la.
Lancez toujours :
avant de tenter une nouvelle compilation.
Supposons maintenant que tout se soit bien passé. Vous devez alors passer sous root et lancer l'installation, ce que vous pouvez faire ainsi :
Et voilà. Une bonne chose à faire serait de vérifier tout de même si le programme tourne... ;-).
Veillez à placer l'exécutable dans un répertoire qui fait partie de votre PATH :
- ou bien vous créez un lien symbolique dans un répertoire du PATH, comme /usr/bin
- soit grâce à la commande ln -sv source destination (où source sera le chemin de l'exécutable et destination le répertoire du PATH où se trouvera le lien)
- soit en utilisant les fonctions de « glisser/lier » d'un outil graphique comme Konqueror
- ou bien encore ajoutez le répertoire de l'exécutable à votre PATH comme indiqué ICI.
Désinstaller
On l'ignore souvent mais il est dans bien des cas tout aussi facile de désinstaller des fichiers que vous avez installés via make install que ce ne l'a été de les installer ! Vous avez simplement besoin du fichier Makefile. En vous plaçant dans le même répertoire que le Makefile, tapez :
il suffit pour que ça marche que l'auteur ait pensé à définir cette cible dans son Makefile (et c'est heureusement souvent le cas).
Si vous installez souvent des programmes à partir des sources, vous pourriez avoir envie de jeter un coup d'œil à CheckInstall, qui construit des RPM simples à partir de programmes compilés et qui installe ensuite ces RPM. Cela rend la suppression de ces programmes beaucoup plus facile (vous pourrez lancer rpm -e name) et cela vous évitera des problèmes de dépendance si vous installez ensuite des RPM qui dépendent de ces fichiers.
Appliquer une rustine
Une rustine (ou encore un patch ou un fichier différentiel - de l'anglais diff file) est un fichier texte d'un format particulier contenant des instructions qui indiquent au programme patch quels changements doivent être effectués dans les fichiers sources et où ces changements doivent être faits.
Une commande de patch ressemble à ceci :
Le point délicat ici réside dans le nombre qui suit immédiatement l'option -p. Ce nombre détermine comment le chemin de fichier qui est indiqué dans le fichier de rustine fichier_de_path doit être appliqué dans le cas de votre système :
- avec -p0 c'est le chemin complet donné dans fichier_de_patch que la commande tentera d'utiliser, avec -p1 le premier niveau d'arborescence du chemin sera supprimé etc.
- si -p n'est pas spécifié du tout le chemin entier sera supprimé, ce qui ne peut fonctionner que si la rustine s'applique exclusivement à des fichiers qui résident tous dans le même répertoire.
Ce qui marche le plus souvent, c'est de mettre le fichier de patch dans le répertoire parent de celui qui contient le répertoire des fichiers sources à patcher et de lancer :
Si ça ne marche pas, essayez d'autres nombres pour l'option -p.
Problèmes rencontrés
(Bien entendu vous avez déjà lu les deux pages précédentes, n'est-ce pas ? ;-))
Fichiers de configuration manquants ou inhabituels
Le répertoire des sources ne contient pas de fichier configure : que faire ?
Dans ce cas vous devrez vous débrouiller avec le Makefile par vos propres moyens.
Seules les quelques lignes du début qui commencent par des mots en majuscules présenteront quelque intérêt pour vous et seront peut-être à modifier. Certains Makefile pourront du reste ne pas contenir toutes ces lignes.
- CC = compilateur dit à make quel compilateur utiliser. GCC devrait marcher dans la plupart des cas. Les programmes écrits dans le langage de programmation C++ pourront requérir plutôt G++.
- INCDIR = -I/chemin/dir1 -I/chemin/dir2 etc. dit à make dans quels répertoires chercher les fichiers d'en-tête. Vérifiez que cela vaut pour votre système.
- LIBDIR = -L/path/dir1 -L/path/dir2 etc. dit à make dans quels répertoires chercher les fichiers de bibliothèque. Vérifiez si c'est correct.
- LIBS = -llib1 -llib2 -llib3 etc. dit à make quelles bibliothèques sont nécessaires. Souvenez-vous que -llib est une abréviation pour liblib.so. Lancez une commande du genre locate liblib.so pour vérifier si les bibliothèques nécessaires sont installées. Parfois cette variable prend le nom de LFLAGS.
Et maintenant, il ne vous reste plus qu'à lancer make.
Que faire si le répertoire des sources contient un fichier Imakefile, GNUmakefile ou Makefile.cvs au lieu de l'habituel Makefile ?
Imake est un programme qui crée un fichier Makefile à partir des indications contenues dans le fichier Imakefile. Pour cela vous devez lancer le script xmkmf et faire :
imake -DUseInstalled -I/usr/X11R6/lib/X11/config
La commande imake et le script xmkmf font partie du paquetage imake.
Il n'y a pas de différence entre les fichiers Gnumakefile et les fichiers Makefile : make les traitera correctement l'un et l'autre.
Si vous avez un Makefile.cvs, lancez :
Cela créera un fichier configure.
Que faire si le répertoire des sources ne contient aucun fichier de configuration ?
Si vous ne trouvez ni configure ni (I)makefile, jetez tout d'abord un coup d'œil dans les sous-répertoires du répertoire des sources pour voir s'ils s'y trouvent. Ensuite, vous pouvez lancer une recherche pour y trouver d'éventuels fichiers exécutables à l'aide de la commande :
qui cherche dans le répertoire courant (".") tous les 'fichiers réguliers' ("-type f") dotés des permissions ("-perm") de lecture, écriture et exécution pour leur propriétaire ("7") et d'aucune de ces permissions pour les membres du groupe propriétaire et pour les autres utilisateurs ("00").
Si vous ne trouvez rien, cela signifie sans doute que vous êtes censé compiler directement les fichiers sources à l'aide du compilateur. C'est particulièrement plausible dans le cas où vous trouvez un unique fichier '\*.c'. Faites alors ceci :
-o nouveau_nom détermine le nom du binaire qui résultera de la compilation. Omettez l'option -o si le répertoire contient plus d'un fichier \*.c (\*.C, \*.cc, \*.cxx). Dans ce cas le binaire issu de la compilation portera le nom par défaut de a.out, vous pourrez ensuite le renommer, si vous le souhaitez, pour lui donner un nom plus approprié.
S'il vous faut définir des répertoires d'en-tête (anglais include) ou de bibliothèques, ou des bibliothèques spécifiques, vous devez le faire en les donnant à gcc en options de la ligne de commande, par exemple ainsi :
("-L" pour 'library', qui signifie 'bibliothèque' en anglais, et "-I" pour include).
Problèmes pendant le processus de construction de l'exécutable binaire
Pourquoi configure réclame-t-il une bibliothèque ou un fichier d'en-tête qui est pourtant installé sur mon système ?
Trois scénarios au moins pourraient conduire à une telle situation :
- configure ne trouve pas le répertoire qui contient la bibliothèque ou le fichier d'en-tête.
- Dans le premier cas, vous devez ajouter le chemin complet du répertoire qui contient la bibliothèque à l'aide de l'option de configure suivante : --with-extra-libs=DIR.
- Vous procéderez de même pour les fichiers d'en-tête mais avec l'option : --with-extra-includes=DIR.
- configure a mis la main sur une mauvaise version de la bibliothèque ou du fichier d'en-tête.
- Un bon exemple de cette situation concerne des applications qui doivent être compilées avec Qt2. configure pourrait échouer et afficher un message d'erreur trompeur, si la version mineure de Qt2 installée était trop ancienne (par exemple la 2.2.1 dans un cas où la 2.2.2 ou une version supérieure serait requise). Dans ce cas vous devez effectuer une mise à jour vers une version mineure postérieure.
- Un autre problème courant apparaît dans le cas ou Qt1 et Qt2 (et Qt3 ...) sont installées. Par défaut, configure cherchera Qt dans '/usr/lib/qt', mais sous Mandriva ceci est le répertoire où Qt1 est installé, Qt2 est dans '/usr/lib/qt2', Qt3 dans '/usr/lib/qt3'. Dans une telle situation vous devez lancer configure ainsi :
./configure --with-qt-dir=/usr/lib/qt2. - NdTrad. : Ces exemples sont en partie obsolètes, mais l'idée générale devrait être claire... Si quelqu'un dispose d'exemples plus à jour qu'il n'hésite pas à les rajouter...
- le script configure contient une faute de frappe.
Examinez avec soin les messages d'erreur dans le fichier config.log, vérifiez notamment la casse des noms des fichiers de bibliothèque ou d'en-tête. C'est une erreur très rare (un ou deux cas en quelques années, pour ce qui me concerne...), mais, croyez-moi, cela peut vraiment vous rendre fou si vous ne pensez pas à cette éventualité ... ;-).
Pourquoi ce binaire que j'ai compilé est-il dépourvu de certaines fonctionnalités qu'il devrait posséder ?
C'est le programmeur qui décide en l'absence de quelle bibliothèque configure ou make devront arrêter la procédure de compilation et afficher un message d'erreur. Une compilation réussie ne garantit donc pas que l'exécutable binaire obtenu possède toutes les fonctionnalités prévues. Examinez soigneusement le fichier config.log pour découvrir quelles bibliothèques n'ont pas été trouvées, installez-les, et lancez à nouveau toute la procédure.
J'ai installé une bibliothèque qui manquait, mais configure ou make ne la trouve toujours pas ! Comment cela se fait-il ?
Les résultats de l'exécution de configure et de make sont mis en cache. Faites :
pour nettoyer complètement le répertoire des sources. C'est la seule façon d'être sûr que ces programmes effectueront une nouvelle vérification du contenu du système.
Si Makefile ne possède pas de cible distclean, alors faites ceci :
Une autre origine possible de ce problème pourrait être que la bibliothèque en question a été installée dans un répertoire qui n'est pas énuméré dans /etc/ld.so.conf. Ce fichier contient la liste de tous les répertoires où ld, l'Editeur de Liens de Linux, recherche des bibliothèques en dehors des répertoires standards de bibliothèques /usr/lib et /lib.
Si par exemple la bibliothèque nouvellement installée est dans /usr/local/lib et si ce répertoire n'est pas mentionné dans /etc/ld.so.conf, cette bibliothèque ne sera pas accessible pour le système.
Pour corriger cela, ajoutez ce répertoire à /etc/ld.so.conf et lancez (en tant que root) :
Ensuite nettoyez le répertoire source et réessayez.
Comment puis-je éliminer des conflits entre des versions de bibliothèques lorsque toutes les bibliothèques requises ont été installées ?
Dans la plupart des cas le processus de construction d'un exécutable ne recherche pas une version mineure spécifique d'une certaine bibliothèque. Il « compte » plutôt sur des liens symboliques, qu'il suppose correctement établis, situés dans le répertoire /usr/lib.
Prenons l'exemple de la bibliothèque libungif.so dans /usr/lib :
lrwxrwxrwx 1 root root 17 2008-03-01 19:28 libungif.so -> libungif.so.4.1.4*
lrwxrwxrwx 1 root root 17 2007-10-10 15:31 libungif.so.3 -> libungif.so.3.1.0*
-rwxr-xr-x 1 root root 29012 2007-08-29 16:09 libungif.so.3.1.0*
lrwxrwxrwx 1 root root 17 2007-10-10 15:31 libungif.so.4 -> libungif.so.4.1.4*
-rwxr-xr-x 1 root root 31892 2007-08-29 16:09 libungif.so.4.1.4*
Comment comprendre tout cela ?
- On voit que deux versions de cette bibliothèque sont installées :
- libungif.so.4.1.4 et libungif.so.3.1.0 (marquées par un * dans la sortie de ls parce qu'il s'agit de fichiers binaires).
- De plus, on trouve trois liens symboliques (parfois appelés symlinks) :
- libungif.so, libungif.so.3 et libungif.so.4.
Les liens symboliques ne sont pas des fichiers « réels », ce sont juste des pointeurs vers d'autres fichiers.
Le processus de compilation/édition de liens pourrait donc chercher libungif.so.3 dans /usr/lib et être renvoyé par le lien symbolique à la version mineure de cette bibliothèque qui se trouve être installée, à savoir la 3.1.0.
Supposons maintenant que le programmeur ait été un peu moins spécifique (un accident peut toujours arriver...) et que de ce fait le processus de compilation/édition de liens soit dirigé vers libungif.so. Dans ce cas il serait renvoyé à la libungif.so.4.1.4, version majeure différente de la même bibliothèque. Or les versions majeures sont souvent incompatibles, et si l'exécutable compte sur la version majeure 3 alors que le processus de construction trouve la version 4 à la place, make ou configure vont être interrompus sur un message erreur, qui se plaindra probablement d'une missing library (bibliothèque manquante) or d'une undefined reference (référence non définie).
De même si un lien symbolique portant le nom d'une version majeure et pointant sur la bibliothèque effectivement installée fait défaut, le processus de construction de l'exécutable sera là aussi en échec.
Dans le premier cas, une solution rapide mais « pas très propre » consisterait à faire pointer le lien sur un autre fichier pour les besoins du processus de compilation/édition de liens en cours :
Si vous vous trouvez dans le second cas, créez le lien symbolique indispensable avec la commande ln. Le premier fichier en argument est le fichier existant, le second est le nom du lien symbolique que vous souhaitez créer et faire pointer sur ce fichier. Vous devrez être prudent en faisant cela, car cela pourrait empêcher l'exécution d'un autre programme. Si c'est possible, demandez conseil au programmeur, qui la est la personne la mieux placée pour vous aider !
Exemple de compilation d'un logiciel
Dans cet article nous allons prendre l'exemple de dillo, un navigateur pour la Toile très léger.
Pour commencer, il faut télécharger l'archive que vous pouvez trouver ici :
http://www.dillo.org/download/dillo-0.8.6.tar.bz2
Nous allons la télécharger et la sauvegarder dans notre répertoire personnel (vous pouvez la sauvegarder où vous voulez, nous avons choisi le répertoire personnel pour que l'explication soit plus simple).
Décompressez l'archive avec la commande tar ou un gestionnaire d'archive graphique (comme ark par exemple).
Si vous utilisez tar, dans un terminal tapez :
Cette commande va décompresser l'archive et va créer un dossier se nommant dillo-0.8.6/.
Maintenant, il faut aller dans le dossier où l'archive a été décompressée. Tapez dans le terminal :
Vous êtes dans le dossier adéquat. Maintenant tapez :
Puis :
Pour l'installation finale du logiciel, vous devez être superutilisateur (autrement dit root). Pour cela, taper la commande su, puis
Voilà l'installation est terminée, mais contrairement à l'installation par gestionnaire de paquets, quand on installe à partir des sources, les dépendances ne s'installent pas automatiquement et on peut donc rencontrer des problèmes tels que :
Glib not found, Dillo needs version >= 1.2.0
Ceci veut dire qu'il faut que vous installer Glib 1.2.0 ou supérieur pour pouvoir installer dillo, c'est pour cela qu'il est conseillé d'utiliser l'installation de paquetages.
Autres ressources
Pour avoir tous les détails les Makefiles, si vous lisez l'anglais : info man
configure ; make ; make install
