Guides des commandes de base sous Linux
Guide des commandes
de base sous Linux

[ Index général ] - [ Page précédente ]

6 - Installer un logiciel à partir des sources

Si les paquetages précompilés sont dune facilité et d'un confort d'utilisation inégalables, il arrive parfois que l'on soit obligé d'installer des logiciels « à la main », parce que le paquetage est mal réalisé ou qu'il nést pas à jour. Nous vous proposons un petit guide pratique d'installation..

NB : dans la suite de cet article, un « $ » désigne l'indicatif de commande de votre shell préféré, exécuté dans votre terminal favori.

Vérifiez votre système

Pour pouvoir compiler des logiciels, vous aurez besoin d'un certain nombre d'outils qui peuvent ne pas être installés sur votre système, si vous avez réalisé une installation minimale du système. Vous aurez besoin, d'une part, d'un outil make et, d'autre part, d'un ou plusieurs compilateurs. Le make fourni avec les distributions Linux est, en général, le GNU make ; celui-ci remplit parfaitement son rôle, cependant, oertaines anciennes versions (en particulier la version 3.76.1) peuvent poser problème.

Quant aux compilateurs, il vous faudra impérativement le GNU (gcc) ou l'une de ses variantes (egcs, pgcc) pour les applications écrites pour KDE ainsi que quelques autres, il vous faudra également le compilateur C++ (g++). Ces compilateurs sont fournis avec votre distribution, n'hésitez pas à les installer à titre préventif, si ce n'est pas déjà le cas.

Attention, le compilateur pgcc (gcc optimisé pour les processeurs Pentium et ultérieurs) fourni, entre autres, avec la distribution Mandrake, a quelques problèmes et peut se montrer incapable de compiler oertains logiciels, là ou gcc fonctionne correctement. Si cela vous arrive, contactez le développeur du logiciel qui dispose peut-être d'une solution à œ problème ; sinon, il vous reste à installer un «véritable» gcc sur votre machine... Pour savoir si votre compilateur est gcc ou pgcc lancez la commande:

$ gcc -v

Cette commande vous indiquera le type et le numéro de version du compilateur.

Trouvez le bon logiciel

Avant de se lancer tête baissée dans le téléchargement, il convient de vérifier de quelle version du logiciel vous avez besoin. Si la plupart de ces logiciels fonctionnent sans problèmes, quelle que soit votre distribution de Linux, certains peuvent être un peu plus sensibles à votre environnement (version de noyau, de XFree, de bibliothèque graphique comme gtk, etc). Un bon exemple en est le client dhcp, dont les versions

fonctionnant sous les noyaux Linux 2.0 ne marchent pas sous les noyaux Linux 2.2, et vice versa.

Même si le logiciel semble à priori tout à fait banal, un petit détour par son site web est indispensable, ne serait-ce que pou- en connaître la dernière version, ainsi que les éventuelles contre-indications de dernière minute. Si vous ne connaissez pas l'url du site, consultez un site de recensement comme la section appindex de Freshrneat http://freshmeat.net/appindex ou Linuxberg http://www.Iinuxberg. com; au passage, vous risquez de découvrir d'autres logiciels sur le même thème qui pourront mieux convenir à vos besoins...

Téléchargez malin

La plupart des logiciels libres développés pour Linux finissent, tôt ou tard, par être disponibles sur au moins l'un des deux plus grands sites ftp dédiés à Linux Metalab (ftp://metalab.unc.edu/pub/Linux) et TSX-1 1 (ftp://tsx-11.mit.edu/pub/Iinux). Ces deux sites ont des miroirs un peu partout dans le monde et, bien entendu, en Franœ, au laboratoire d'informatique de Paris 6 (ftp://ftp.lip6.fr/pub/Iinux/ sunsite, ftp://ftp.Iip6.fr/pub/Iinux/tsx-11). Aussi, plutôt que de télécharger les sources du logiciel depuis son site web principal, pensez àutiliser un miroir, vous économiserez du temps et de la bande passante...

Vérifiez les dépendances

Quoi de plus frustrant que de télécharger la toute nouvelle version de Xlntercal, l'environnement de développement visuel de votre langage préféré, pour vous rendre compte au moment de le compiler que vous avez ("bon sang, mais c'est bien sCr" !) oblié de récupérer également la dernière version de la bibliothèque graphique iAbstain dont il ne peut absolument pas se passer!

Prenez le temps de parcourir le site web du logiciel. Il ne manquera pas de dresser la liste des bibliothèques et utilitaires pouvant ne pas être présents sur votre système et précisera généralement à quel endroit les télécharger, s'ils ne sont pas encore sur Metalab et ses miroirs...

Choisissez les bons fichiers

Les sources des logiciels sont, en règle générale, disponibles sous forme archivée. li peut s'agir, soit d'un fichier .zip, soit d'une archive .tar compactée par gzip (.tar.gz ou .tgz, plus rarement .taz ou .tar.Z) ou par bzip2 (.tar.bz2 ou .tbz2). L'usage veut que le nom de fichier contienne également le numéro de version. Par exemple, Xlntercal-1.3.66.tar.gz désignera la version 1.3.66 de Xlntercal, sous la forme d'une archive tar compactée par gzip.

Vous avez tout intérêt, sauf contre-indication pour votre système, àchoisir la version la plus récente. En œ qui concerne le type d'archives à récupérer, cela dépend de votre système. Les archives les plus

  • compactes sont, le plus souvent, celles au format .tar.bz2 ; cependant, le programme bzip2 nécessaire pour les décompacter n'est pas systématiquement installé par les distributions Linux ; vérifiez si bzip2 est installé su votre système en lançant
  • $ bzip2 --help
  • depuis un terminal. Si vous obtenez un message d'erreur, c'est que bzip2 n'est pas installé sur votre système (ou alors, n'est pas dans l'un des répertoires de votre variable d'environnement PATH). Attention, il se peut que vous ayez bzip, mais pas bzip2. Ces deux programmes sont différents et non interchangeables : bzip ne pourra pas décompacter des archives .tar.bz2...
  • Gzip, quant à lui, est installé par la quasi-totalité des distributions et, sinon, il est fourni su le cédérom d'installation. Si vous n'êtes pas en mesure d'exploiter les archives .tar.bz2, préférez les archives .tar.gz aux .zip, qui sont souvent plus grosses et nécessitent le programme unzip qui peut, lui aussi, ne pas avoir été installé par votre distribution.

En plus de l'archive de la dernière version des sources, il se peut que

vous deviez télécharger des «rustines» (patchs) afin de mettre à jour les

• sources. La nomenclature habituelle de ces fichiers est de la forme

patch-logiciel-version1-version2.diff, pour le patch permettant de

passer

de la version 1 du logiciel à la version2. Ces fichiers sont fréquemment compactés par gzip ou bzip2, ce qui pourrait donner dans

  • notre exemple:
  • patch-Xlntercal-1.3.66-1.3.66a.diff.bz2
  • pour un patch permettant de mettre à jour la version 1.3.66 en 1 .3.66a.
  • Les patchs sont cumulatifs, sauf mention contraire dans la documentation ; autrement dit, pour pouvoir obtenir la version 1.3.66c de Xlntercal, il vous faudra récupérer, en plus de l'archive complète 1.3.66, les fichiers patchs 1.3.66-1.3.66a, 1.3.66a-1.3.66b et 1 .3.66b- 1 .3.66c.
  • Si vous avez une connexion internet lente (par modem, par exemple), et que vous avez une archive complète .tar.gz d'une version antérieure, vous pouvez économiser du temps et de la bande passante en téléchargeant uniquement les patchs dont vous avez besoin, même s'il existe une archive complète plus récente. Le meilleur exemple en est le noyau Linux, dont les sources complètes occupent actuellement un peu plus de 15 Mo en .tar.gz, et dont les patchs dépassent rarement 1 Mo il est bien plus économique de récupérer deux ou trois patchs plutôt que la dernière archive complète en date...
  • Méfiez-vous, si vous téléchargez depuis Netscape (ou Mozilla), celui-ci se fera un plaisir, selon votre configuration, de décompacter les fichiers .gz ; cependant, il peut arriver aussi qu'il enregistre le fichier sans l'extension .gz, tout en laissant les données compactées. Pensez àvérifier, après le téléchargement, dans quel état sont les fichiers à l'aide de la commande file:
  • $ file Xlntercal-1.3.66.tar.gz Xlntercal-1.3.66.tar Xlntercal-1.3.66.tar.gz: gzip compressed data E...] Xlntercal-1 .3.66.tar: GNU tar archive
  • $
  • Si vous obtenez «GNU tar archive» ou «POSIX tar archive», le fichier a
  • été décompacté ; en revanche, si vous obtenez «gzip compressed data», le fichier est bel et bien un fichier .gz. Si votre distribution date un peu, il se peut que les fichiers .bz2 ne soient pas identifiés en tant que tels et soient, tout simplement, désignés par «data».

Décompactez les sources

Une fois votre marché terminé, choisissez-vous un répertoire de travail dans lequel vous aurez suffisamment de place pour stocker les sources du logiciel et sa version compilée, ainsi que les fichiers intermédiaires de la compilation. Un sous-répertoire de /tmp convient la plupart du temps.

La majorité des archives sources contiennent un répertoire reprenant le nom et le numéro de version du logiciel et dans lequel se situe toute l'arborescence des sou-ces en elles-mêmes ; ainsi, décompacter l'archive Xlntercal- 1 .3.66.tar.gz produirait un répertoire Xlntercal- 1.3.66 contenant tous les fichiers sou-ce. Cependant, vous risquez de rencontrer, de temps à autre, une brebis galeuse qui remplira le répertoire courant d'une multitude de fichiers

Vérifiez donc le contenu de l'archive (œ qui, au passage, devrait vous permettre de vous assurer que le téléchargement s'est déroulé correctement et que l'archive n'est pas corrompue). Dans le cas d'une archive .zip, lancez

$ unzip -l Xlntercal-1.3.66.zip

pour en afficher le contenu; vous pouvez aussi préférer «unzip -t», qui en profitera pour tester l'intégrité de l'archive. Pour les archives .tar, la commande est

$ tar -M Xlntercal-1.3.66.tar

(le tiret pouvant être omis avec la version GNU de tar). Si l'archive est compactée, décompactez-là au vol : si elle est compactée par gzip, il vous suffit d'ajouter la lettre z aux options de tar (tar tvzf Xlntercal-1.3.66.tar.gz) ; si elle est compactée par bzip2, la commande est un peu plus scabreuse, il s'agit de faire

$ bunzip2 -c Xlntercal-1.3.66.tar.bz2 I tar -tvf -

(ou «I tar tv» avec la version GNU de tar).

La liste des fichiers défilant, vous pouvez voir si les fichiers seront tous extraits dans un sous-répertoire ou en vrac, dans le répertoire courant dans ce dernier cas, le mieux est de créer un répertoire supplémentaire pour pouvoir plus facilement faire place nette:

$ mkdir Xlntercal

$ cd Xlntercal

Il reste à faire l'extraction des sources proprement dite. Reprenez la commande que vous avez utilisée pour lister le contenu de l'archive; s'il s'agit d'une archive .zip, retirez-en le paramètre -l (ou -t)

$ unzip Xlntercal-1.3.66.zip

S'il s'agit d'une archive .tar, compactée ou non, remplacez la lettre t par la lettre x dans les options de tar:

$ bunzip2 -c Xlntercal-1.3.66.tar.bz2 I tar -xvf -

Appliquez les patchs, dans la joie et la bonne humeur...

L'application des patchs, s'il y a lieu, est souvent considérée à la fois comme une opération périlleuse et comme une cérémonie Unixienne incompréhensible ; il n'en est rien, mais c'est une opération effectivement baroque à première vue.

Les fichiers patchs sont des fichiers textes, d'un format bien déterminé, générés par la commande diff (d'où leur extension) ; si leur créateur est consciencieux, il a ajouté en tête les quelques instructions nécessaires pour les appliquer correctement. Pour pouvoir les lire, il convient de décompacter les fichiers:

$ bunzip2 patch-Xlntercal-1.3.66-1 .3.66a.diff.bz2

$ gunzip patch-Xlntercal-1.3.66a-1.3.66b.diff.gz

Si vous préférez conserver ces fichiers sous forme compactée, vous pouvez les consulter avec more (ou less) et un décompactage au vol:

$ bunzip2 -c patch-Xlntercal-1 .3.66-1 .3.66a.diffbz2 I more

$ gunzip -c patch-Xlntercal- 1.3.66a- 1.3.66b.diff.gz I more

(appuyez sur la touche q pour quitter more sans avoir à parcourir tout le fichier).

Vous avez pu constater si le fichier contient des instructions d'utilisation ;Si c'est le cas, suivez-les en toute confiance, sinon, il s'agit très probablement d'un patch «standard». Pour le vérifier, placez-vous dans le répertoire des sources et donnez le contenu du fichier patch en entrée de la commande du même nom:

$ Is patch*

patch-Xlntercal-1.3.66.diff

$ cd Xlntercal

$ patch -pi <.Jpatch-Xlntercal-i.3.66.diff

Si la commande patch vous pose l'angoissante question «file to patch?», interrompez-là (par contrôle-C) et retentez l'opération avec le paramètre

-pU au lieu de -pi. Si cette option ne convient pas non plus, vous faites partie des innocentes victimes de la commande patch (et du laisser-aller de la part du concepteur du fichier patch qui aurait pu donner des instructions d'installation...) Il vous reste deux choix : vous plonger dans la lecture de la page de manuel de la commande patch et celle du fichier récalcitrant, afin de déterminer les bonnes options ; ou, plus reposant, d'attendre la parution d'une archive .tar.gz plus récente, permettant de se passer des patchs!

Parmi les autres obstacles que peut semer patch sur votre route, nous nous devons de mentionner les fichiers de rejet. Si patch vous affiche un message d'erreur signalant qu'un morceau du fichier a provoqué un rejet, il est alors fort probable que les fichiers n'ont pas été appliqués dans le bon ordre ou que vous ne partez pas de la bonne archive des sources. Dans ce cas, les sources sont certainement inutilisables ; effacez le répertoire et recommencez le décompactage à zéro, c'est plus prudent.

Comment compiler

Une fois les sources décompactées et patchées, si nécessaire, vous êtes prêt pour la compilation tant attendue. Commencez cependant par freiner votre ardeur et consultez les fichiers de documentation présents parmi les sources. Le fichier README (ou apparenté : LISEZMOI, RE.AD.ME, etc.) contiendra probablement des informations de la plus grande importance le fichier INSTALL, s'il existe, est aussi d'une lecture recommandée. S'il ne semble pas y avoir de documentation, recherchez un éventuel répertoire «doc» ou «instali» qui pourrait contenir ces fichiers.

Avant de compiler un logiciel, vous devez le configurer pour l'adapter au système. Par configuration, entendez là le choix des particularités Unixiennes à utiliser (ou ne pas utiliser...), dans le cas d'un programme portable entre plusieurs variétés de systèmes Unix (telle fonction sera présente sous Linux mais pas, par exemple, sous Solaris et vice-versa; si la fonction est absente, on la remplacera par une fonction équivalente), ainsi que le choix des divers répertoires dans lesquels devra s'installer le logiciel. Par exemple, un étudiant ne pourra probablement pas installer Xlntercal dans /usr/bin sur les machines de l'université, car

il n'est pas administrateur des machines ; en revanche, il peut très bien l'installer dans $HOMEkin, où il règne en maître.

Grosso modo, on peut diviser les logiciels en trois catégories:

- ceux qui se configurent à l'aide d'un script nommé... configure;
- ceux qui se configurent à l'aide d'un fichier Imakefile; et tous les autres.

Les scripts configure

Les logiciels se configurant à l'aide d'un script configure sont de plus en plus répandus, car il s'agit de la méthode la plus puissante pour adapter le logiciel au système sur lequel il doit être compilé. En particulier, tous les logiciels GNU, dans leurs versions d'après 1994 environ, se configurent de cette façon.

Tous les scripts configure reconnaissent un certain nombre d'options, parmi lesquelles --pref ix, qui permet de spécifier dans quelle arborescence doivent être installés les fichiers. Par défaut, il s'agit de /usr/local, un choix judicieux, car il évite de semer la zizanie parmi le reste du système (et les paquetages officiels de votre distribution), installé dans /usr. Cependant, d'un logiciel à l'autre, ce répertoire peut varier ; ainsi, les sources de KDE proposent /opt/kde à la place de /usr/local.

Par défaut, les exécutables (binaires) seront alors installés dans /usr/local/bin, les fichiers de configuration dans /usr/local/etc, les f ichiers d'en-tête dans /usr/local/include, les bibliothèques dans /usr/local/lib, les pages de manuel dans /usr/local/man (et /usr/local/info pour les manuels info) et les fichiers de données dans /usr/local/share. Cependant, il est possible d'affiner cette sélection à l'aide des options

--exec-prefix, --sysconfdir, --includedir, --Iibdir, --mandir (et --infodir), --datadir, etc. Ainsi la commande:

$ Jconfigure --prefix=/usr/Iocal --sysconfdir=/etc

configure le logiciel pour s'installer dans l'arborescence /usr/local, mais en plaçant ses fichiers de configuration dans le répertoire /etc.

Si le logiciel dispose de fonctionnalités optionnelles, celles-ci sont, en général, activables à l'aide d'option de la forme --enable-fonction, pour les activer, et --disable-fonction, pour les désactiver:

$ Jconfigure --enable-truc --disable-bidule

configure le logiciel avec la fonction "truc" mais sans la fonction "bidule".

En fonction des bibliothèques installées sur votre système et que vous souhaitez (ou souhaitez ne pas) utiliser, il peut exister d'autres options de la forme --with-bibliothèque, pour les utiliser, et --withoutbibliothèque, pour ne pas les utiliser:

$ Jconfigure --without-kdelibs --with-gnomelibs

configure le logiciel en utilisant les bibliothèques de Gnome mais pas celles de KDE. Il peut être parfois nécessaire de préciser dans quelle arborescence est installée telle bibliothèque ; il n'y a pas de règle générale, selon le script, cela peut prendre la forme:

$ Jconfigure --with-gnomelibs=/usr/Iocal/gnome

ou

$ Jconfigure --with-gnomelibs --with-gnome-dir=/usr/Iocal/gnome

Une liste exhaustive des options, ainsi que leur valeur par défaut, peut être obtenue en lançant tout simplement

$ Jconfigure --help

Le résultat peut fréquemment dépasser 100 lignes, pensez à utiliser

cette commande avec more ou less:

$ Jconfigure --help I less

Cela sera probablement plus agréable à lire.

Une fois déterminées vos options, lancez configure avec les paramètres adéquats. Le script effectuera tous les tests indispensables pour adapter le programme à votre configuration particulière (vérification du compilateur utilisé, des bibliothèques présentes, etc.). Les tests défilent à l'écran, s'affichant sous la forme de lignes «checking (telle caractéristique).., résultat», ce qui vous permet de patienter ou de vous endormir...

Une trace de ces messages est conservée dans config.log, et une trace des résultats dans config.cache; ainsi, si configure n'arrive pas à trouver une bibliothèque, que vous l'installiez, mais que configure persiste à ne pas la voir, pensez à effacer ce fichier avant de relancer configure : c'est sans danger et peut faire sensiblement "avancer le schmilblick"

Si l'un des tests de configure est considéré comme fatal, il ne sera pas possible de compiler le logiciel ; vous n'aurez d'autre choix que de résoudre le problème, par exemple, en installant une bibliothèque manquante ou en relançant configure avec une option --disable-truc (ou

--without-machin) supplémentaire ou en suivant les éventuelles indications affichées par le script.

Dans les cas difficiles, il peut être utile de forcer configure à utiliser

tel ou tel compilateur ou telles ou telles options, par le biais de variables d'environnement:

$ CFLAGS="-I/usr/Iocal/include" LDFLAGS="-L/usr/Iocal/lib" Jconfigure

permet, par exemple, de faire «comprendre» à un script configure récalcitrant qu'il doit passer certaines options au compilateur et d'autres à l'éditeur de liens. Cette manière forte (mais efficace), ainsi que d'autres astuces, sont généralement décrites dans le fichier INSTALL. Si tout se passe bien, configure va générer un certain nombre de fichiers reprenant les résultats de ses tests, et, surtout, les précieux Makefile.

Il ne vous reste plus qu'à compiler par

$ make

vérifier le bon fonctionnement du logiciel, si des tests ont été prévus, par $ make check

et installer le logiciel, par

$ make install

Si vous préférez reprendre la configuration à zéro, par exemple pour relancer configure avec de nouvelles options, lancez la commande

$ make distclean

pour revenir dans une situation propre.

Imake

Si le répertoire des sources contient un fichier nommé Imakefile, il y a fort à parier que votre logiciel se configure avec imake. S'il existe aussi un script configure, préférez-le cependant, car plus puissant.

L'utilitaire imake ne sera présent sur votre système que si vous avez installé le système X-Window. En effet, le rôle d'imake est de configurer

les applications Xii (même s'il peut être utilisé à d'autres fins), et il nécessite absolument un certain nombre de fichiers de configuration qui traînent dans le répertoire lib/X1 i/config de l'arborescence Xii du système.

La documentation du logiciel vous indiquera probablement un fichier particulier de configuration à modifier, en fonction de vos choix de répertoires, ce fichier étant inclus par le fichier Imakefile principal parfois, les modifications sont à faire dans le fichier Imakefile lui-même. Quelle que soit la situation, pensez à faire une copie de sauvegarde des fichiers avant de les modifier, on ne sait jamais

Une fois votre fichier Imakefile prêt, il vous reste à lancer imake pour générer de véritables Makefile. Cependant, imake ne se lance pas directement, mais par le biais de la commande xmkmf:

$ xmkmf

Le script xmkmf a généré un fichier Makefile dans le répertoire courant; il reste à configurer les sous-répertoires. C'est chose faite avec:

$ make Makefiles

Puis, la compilation proprement dite a lieu, en lançant make sans paramètres (ou «make World» pour certains logiciels <(vieux jeu»). Ensuite, consultez les instructions fournies avec le logiciel pour l'installation ou toute phase supplémentaire ; cependant, il est très probable qu'un simple make install suffise.

Et les autres?

Si le logiciel qui vous intéresse est un petit projet ou en est aux premiers stades de son développement, il est fréquent qu'il n'utilise pas (encore) un système évolué de génération de Makefile comme autoconf ou imake. Il peut aussi avoir de bonnes raisons d'utiliser un système maison : le noyau Linux, par exemple, serait très pénible à configurer avec un script configure, étant donné sa multitude d'options ; et la bibliothèque graphique Qt, utilise le même système de Makefile sous environnement Windows, alors que ni imake ni autoconf ne fonctionnent sous ce système.

Dans ce cas, la meilleure source d'informations est la documentation qui accompagne le logiciel ; si celui-ci se compose de quelques fichiers seulement et d'un Makefile, l'éditer pour indiquer les chemins d'installation désirés et les options de compilation se révèle généralement suffisant.

Pour les cas désespérés, une autre source d'informations peut être le fichier de configuration du paquetage du logiciel pour une distribution Linux ; même si le paquetage concerne une version plus ancienne, ou une distribution différente de celle que vous utilisez, il est fort probable que la technique de compilation ne changera pas d'un iota.

Si tous vos efforts sont demeurés vains, il vous reste alors à contacter votre gourou Unix local, ainsi que le groupe d'utilisateurs de votre région; l'un d'entre eux saura bien vous dépanner... Enfin, ne désespérez pas, le logiciel finira par être disponible sous forme d'un paquetage pour votre distribution préférée et nous nous empresserons alors de vous le proposer sur l'un des cédéroms de Planète LINUX!

Bonnes compilations!

[ Index général ] - [ Page précédente ] - [ Page suivante ]


[ Home Page ] - [ Introduction ] - [ Sommaire ] - [ Pourquoi Linux ] - [ Qu'est ce que Linux ? ] - [ Qui, Quoi, Ou ? ]
[
Les indispensables ] - [ Guide des commandes ] - [ Mes lectures ! ] - [ Documentations ]
[
Linux sur le WEB... ] - [ Spéciales Bookmarks... ] - [ Trucs & Astuces ] - [ Glossaire ]