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
- 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
- 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!
|