Installation d'un logiciel libre APRIL (Association pour la Promotion et la Recherche en Informatique Libre) On me demande souvent comment installer un logiciel libre à partir de sources. Compiler soit même un logiciel est pourtant très simple car la plupart des étapes à passer sont les mêmes quelque soit le logiciel à installer. Le but de ce document est de guider pas à pas le débutant, en essayant d'éviter l'écueil de l'incantatoire, et en lui expliquant sommairement la signification de chacune des manipulations. J'assume cependant que le lecteur ait un minimum de connaissances Unix (de type ls ou mkdir). Ce guide reste un guide, et pas un manuel de référence. C'est pourquoi un certain nombre de pointeurs sont fournis à la fin afin de répondre aux questions sans réponse. Ce guide est toujours en version béta, j'attend donc avec impatience toute remarque ou correction sur son contenu. _________________________________________________________ Table des matières 1. Introduction 1.1. Pré-requis 1.2. Compilation 1.2.1. Principe 1.2.2. Les quatre phases de la compilation 1.3. Structure d'une distribution 2. Décompactage 2.1. Archive tar.gz 2.2. Utilisation de GNU Tar 2.3. bzip2 2.4. Just do it ! 2.4.1. Le plus simple 2.4.2. Le plus sûr 3. Configuration 3.1. Autoconf 3.1.1. Principe 3.1.2. Exemple 3.1.3. Et si... ça ne marche pas ? 3.2. Imake 3.3. Scripts shells divers 3.4. Autres alternatives 4. Compilation 4.1. Make 4.2. Règles 4.3. Go, go, go !!! 4.4. Explications 4.5. Et si ça ne fonctionne pas ? 5. Installation 5.1. Avec make 5.2. Problèmes 6. Support 6.1. Documentation 6.2. Support technique 6.3. Comment trouver des logiciels libres 7. Remerciements 8. Copyright 1. Introduction Ce qui différencie un logiciel libre d'un logiciel propriétaire est l'accès aux sources du logiciel.[1] Ce qui implique que les logiciels libres soient généralement distribués sous forme d'archives de fichiers sources. C'est assez déroutant pour le débutant, car l'utilisateur du logiciel doit compiler lui-même les sources du logiciel avant de pouvoir l'utiliser. Aujourd'hui, il existe des versions pré-compilées de la plupart des logiciels libres existants. L'utilisateur pressé n'a plus qu'à installer le binaire. Cependant, certains logiciels ne sont pas distribués sous cette forme, ou les versions les plus récentes ne sont pas encore distribuées sous cette forme. De plus, si vous utilisez un couple système d'exploitation / architecture exotique, beaucoup de logiciels libres ne seront pas déja précompilés pour vous. Par ailleurs, compiler soi même ses logiciels permet de ne conserver que les options intéressantes ou d'étendre les fonctionnalités du logiciel en appliquant des extensions afin d'obtenir un logiciel répondant parfaitement à ses besoins. Notons que je ne traiterais pas dans cette documentation de l'installation d'un logiciel à partir de binaires, ce qui devrait être détaillé dans la documentation de votre système d'exploitation (packages .deb, .rpm, ou tarballs de BSD ou de la distribution Slackware). _________________________________________________________ 1.1. Pré-requis Pour installer un logiciel libre, vous aurez besoin : * d'un ordinateur allumé pourvu d'un système d'exploitation, * d'un peu d'espace disque, * d'un compilateur (généralement C), d'un programme d'archivage (tar), * d'une connaissance généraliste du système d'exploitation que vous utilisez, * de quoi manger (dans les mauvais cas, ça peut durer longtemps). Un vrai informaticien mange des sandwiches grecs, pas de Mac Donalds, * de quoi boire (pour les mêmes raisons). Un vrai informaticien boit du Jolt Cola (pour la caféine), mais à défaut, du Coca suffira, * du numéro de téléphone de votre copain bidouilleur qui recompile son noyau toutes les semaines, * mais surtout de patience (beaucoup). Compiler un logiciel libre ne présente généralement pas trop de problèmes, mais si vous n'êtes pas habitué, la moindre anicroche peut vous plonger dans la confusion. Le but de ce document est justement de vous montrer comment vous sortir de ce genre de situation. _________________________________________________________ 1.2. Compilation 1.2.1. Principe Pour passer d'une forme source à une forme binaire, il est nécessaire d'effectuer une compilation. Cette compilation est généralement effectuée sur des programmes écrits en langage C ou C++ (qui sont les plus répandus dans la communauté du logiciel libre). Certains logiciels libres sont écrits dans des langages ne nécessitant pas de compilation (par exemple Perl ou shell), mais ils ont quand même besoin d'être configurés. La compilation C est assurée très logiquement par un compilateur qui est généralement gcc, le compilateur libre écrit par le projet GNU. La compilation d'un logiciel entier est une tâche complexe, qui passe par la compilation successive de multiples fichiers sources (il est plus facile pour le programmeur d'isoler les différentes parties de son travail dans des fichiers distincts). Afin de faciliter la tâche, ces opérations répétitives sont effectuées par un utilitaire du nom de make. _________________________________________________________ 1.2.2. Les quatre phases de la compilation Pour bien comprendre le mécanisme de la compilation (et donc être à même de résoudre des problèmes éventuels), il faut savoir qu'elle s'effectue en quatres phases. Il s'agit d'une conversion progressive (en quatre étapes) d'un texte écrit dans un langage compréhensible par un humain entraîné (langage C par exemple) vers un langage compréhensible par une machine (ou un humain très entraîné). gcc exécutera l'un après l'autre quatre programmes qui se chargeront chacun d'une étape : 1. cpp: la première étape consiste à remplacer des directives (préprocesseurs) par des instructions C. Typiquement, il s'agit d'insérer un fichier d'en-tête (#include) ou de définir une macro fonction (#define). À la fin de cette phase, un code purement C est généré. 2. cc1 : cette étape consiste à convertir du C en assembleur. L'assembleur généré est dépendant de l'architecture cible. 3. as : cette étape consiste à générer du code objet (binaire) à partir d'assembleur. À la fin de cette phase, un fichier se terminant par .o est généré. 4. ld : cette dernière étape (linkage) assemble (lie) tous les fichiers objets (.o) et les bibliothèques associées, et génère un exécutable. _________________________________________________________ 1.3. Structure d'une distribution Une distribution de logiciel libre correctement structurée est généralement organisée d'une manière bien précise : * un fichier INSTALL, qui décrit la procédure d'installation du logiciel, * un fichier README qui contient toutes les informations générales relatives au programme (courte description, auteur, adresse où le télécharger, documentation relative, pointeurs utiles, ...). Si le fichier INSTALL est absent, le fichier README contient généralement une procédure succincte d'installation, * un fichier COPYING qui contient la licence ou décrit les conditions de distribution du logiciel. Parfois, un fichier LICENCE est rencontré a la place, * un fichier CONTRIB ou CREDITS qui contient une liste de personnes ayant un rapport avec le logiciel (participation active, remarques pertinentes, logiciel tiers, etc.). * un fichier CHANGES (ou plus rarement NEWS), qui contient les nouveautés de la version actuelle par rapport à la version précédente, * un fichier Makefile (voir la section Make), qui permet de compiler le logiciel (c'est un fichier nécessaire à make). Souvent, ce fichier n'existe pas encore et sera généré lors du processus de configuration, * assez souvent un fichier configure ou Imakefile, qui permettra de générer un nouveau fichier Makefile, * un répertoire contenant les sources, qui sera généralement celui où le binaire sera stocké une fois la compilation finie. Son nom est généralement src, * un répertoire contenant la documentation relative au programme (généralement au format man ou Texinfo), dont le nom est généralement doc, * éventuellement un répertoire contenant des données propres au logiciel (typiquement des fichiers de configuration, des exemples de données produites, ou des fichiers de ressources). _________________________________________________________ 2. Décompactage 2.1. Archive tar.gz Le standard de compression sous les systèmes UNIX est le format gzip, développé par GNU, et considéré comme un des meilleurs outils de compression généralistes. gzip est souvent associé à un utilitaire nommé tar. tar est un rescapé des temps préhistoriques où les informaticiens stockaient leurs informations sur des bandes magnétiques. Aujourd'hui, les disquettes et les CD-ROM ont remplacé les bandes magnétiques, mais tar est toujours utilisé pour créer des archives. Il est par exemple possible de concaténer (mettre à la suite) tous les fichiers d'un répertoire dans un seul fichier tar. Ce fichier peut ensuite être facilement compressé à l'aide de gzip. C'est pourquoi de nombreux logiciels libres sont disponibles sous la forme d'archives tar, compressées avec gzip. Leur extension est donc .tar.gz (ou encore, sous forme abrégée, .tgz). _________________________________________________________ 2.2. Utilisation de GNU Tar Pour décompresser cette archive, on peut utiliser gzip, puis tar ensuite. Mais la version GNU de tar (gtar) permet d'utiliser gzip à la volée, et ainsi de décompresser une archive de manière transparente. L'utilisation de tar est incantatoire : tar options fichier.tar.gz fichiers L'option fichiers est falcutative. Dans le cas où elle est omise, le traitement s'effectuera sur toute l'archive. Si vous voulez extraire le contenu d'une archive .tar.gz, alors vous n'avez certainement pas besoin de spécifier cet argument. Par exemple : $ tar xvfz guile-1.3.tar.gz -rw-r--r-- 442/1002 10555 1998-10-20 07:31 guile-1.3/Makefile.in -rw-rw-rw- 442/1002 6668 1998-10-20 06:59 guile-1.3/README -rw-rw-rw- 442/1002 2283 1998-02-01 22:05 guile-1.3/AUTHORS -rw-rw-rw- 442/1002 17989 1997-05-27 00:36 guile-1.3/COPYING -rw-rw-rw- 442/1002 28545 1998-10-20 07:05 guile-1.3/ChangeLog -rw-rw-rw- 442/1002 9364 1997-10-25 08:34 guile-1.3/INSTALL -rw-rw-rw- 442/1002 1223 1998-10-20 06:34 guile-1.3/Makefile.am -rw-rw-rw- 442/1002 98432 1998-10-20 07:30 guile-1.3/NEWS -rw-rw-rw- 442/1002 1388 1998-10-20 06:19 guile-1.3/THANKS -rw-rw-rw- 442/1002 1151 1998-08-16 21:45 guile-1.3/TODO Parmi les options à passer à tar : * v permet de rendre tar verbeux. C'est à dire qu'il affichera à l'écran tous les fichiers qu'il trouve dans l'archive. Si cette option est omise, alors le traitement sera silencieux. * f est une option obligatoire. Sans cette option, tar essaiera d'utiliser une bande magnétique à la place d'un fichier d'archive (c'est à dire le device /dev/rmt0). * z permet de manipuler une archive compressée par gzip (suffixe .gz). Si vous oubliez cette option lors du décompactage d'une archive compressée, alors tar produira une erreur. Inversement, si vous êtes en face d'une archive non compressée, n'utilisez pas cette option. * tar permet d'effectuer plusieurs manipulations différentes sur une archive (extraction, lecture, création, ajout...). Une option permet de spécifier l'usage qui en est fait : + x : cette option permet d'extraire des fichiers de l'archive, + t : cette option permet de tester l'intégrité de l'archive. utilisée en combinaison avec l'option v, elle permet de lister le contenu de l'archive, + c : cette option permet de créer une archive, ce qui implique détruire son contenu actuel. Cette option n'est intéressante pour vous que dans le cas de votre usage personnel (vos sauvegardes, par exemple), + r : cette option permet d'ajouter des fichiers à la fin de l'archive. Elle ne fonctionne pas dans le cas d'une archive compressée. _________________________________________________________ 2.3. bzip2 Un format de compression nommé bzip2 tend en ce moment à remplacer gzip. bzip2 produit des archives de taille plus petite que gzip, mais n'est pas encore un standard de fait. On trouve donc depuis peu des archives à l'extension .tar.bz2. bzip s'utilise de la même manière que gzip par le biais de la commande tar. Il suffit de remplacer la lettre z par la lettre I. Par exemple sous GNU/Linux : $ tar xvfI pouet.tar.bz2 Sous BSD : $ tar xvfy pouet.tar.bz2 Une autre possibilité (qui semble être plus portable, mais plus longue!) : $ tar --use=bzip2 -xvf pouet.tar.bz2 Je précise qu'il est nécessaire que bzip2 soit installé et inclut dans la variable PATH avant d'exécuter tar ! _________________________________________________________ 2.4. Just do it ! 2.4.1. Le plus simple Maintenant que vous êtes prêt à décompacter l'archive, n'oubliez pas de le faire en tant qu'administrateur (root). En effet, vous allez avoir besoin de faire des manipulations qu'un simple utilisateur ne peut faire. Commencez par vous rendre dans le répertoire /usr/local/src, et copiez l'archive dans ce répertoire. Cela vous permet de retrouver à tout moment l'archive si vous perdez le logiciel installé. Si vous n'avez pas beaucoup de place disque, alors sauvegardez l'archive sur disquette après avoir installé le logiciel, ou alors effacez-la, mais soyez sûr de pouvoir la retrouver sur le net à tout moment. Normalement, le décompactage d'une archive tar devrait créer un nouveau répertoire. Rendez vous maintenant dans ce répertoire, vous êtes prêt à continuer. _________________________________________________________ 2.4.2. Le plus sûr Le système Unix (dont font partie GNU/Linux et FreeBSD) est un système sécurisé. Cela signifie que les utilisateurs normaux ne peuvent pas effectuer des opérations qui mettraient le système en danger (comme par exemple formater un disque), ni altérer les fichiers des autres utilisateurs. Dans la pratique, cela imunise aussi le système aux virus. En revanche, l'utilisateur root à le droit de tout faire, y compris d'exécuter un programme malicieux (virus). La disposition du code source est une garantie de sécurité face aux virus, mais vous avez tout à fait le droit d'être paranoïaque[2]. L'idée consiste à créer un utilisateur dédié à l'administration (free ou admin par exemple) par le biais de la commande adduser. Ce compte devra avoir le droit d'écrire dans le répertoire /usr/local/src ainsi que dans les répertoires /usr/local/bin, /usr/local/lib et toute l'arborescence de /usr/man (il se peut qu'il nécessite aussi de copier des fichiers ailleurs). Pour cela, je vous recommande soit de rendre cet utilisateur propriétaire des répertoires nécessaires, soit de créer un groupe pour lui, et de rendre ces réertoires accessibles en écriture pour ce groupe. Une fois que ces précautions sont prises, vous pouvez effectuer les manipulations décrites dans la section Le plus simple. _________________________________________________________ 3. Configuration Un intérêt purement technique de la disposition des sources est le portage du logiciel. Un logiciel libre développé pour un UNIX (vaste famille de systèmes d'exploitation dont GNU/Linux fait partie) est utilisable sur tous les UNIX existants (libres ou non libres), avec cependant quelques modifications. Ceci nécessite une configuration du logiciel juste avant la compilation. Il existe plusieurs systèmes de configuration, il va falloir utiliser celui prévu par l'auteur du logiciel (parfois, plusieurs sont prévus). Généralement : * utiliser autoconf (voir la section Autoconf) dans le cas où un fichier configure existe dans le répertoire parent de la distribution * utiliser Imake (voir la section Imake) dans le cas où un fichier Imakefile existe dans le répertoire parent de la distribution * exécuter un script shell (par exemple install.sh) selon ce que dit le fichier INSTALL (ou README) _________________________________________________________ 3.1. Autoconf 3.1.1. Principe autoconf permet de configurer correctement un logiciel. Il crée les fichiers nécessaires à la compilation (Makefile par exemple), et modifie parfois directement les sources (par exemple par le biais d'un fichier config.in). Le principe d'autoconf est simple : * l'auteur du logiciel sait quels tests sont nécessaires pour configurer son logiciel (ex: "quelle version de cette librairie utilise tu ?"). Il les écrit dans un fichier nommé configure.in, en suivant une syntaxe précise. * il exécute autoconf. Ce dernier génère à partir du fichier configure.in un script de configuration appelé configure. Ce script est celui qui effectuera les tests nécessaires à la configuration du programme. * l'utilisateur final exécute ce script, et autoconf se charge de configurer tout ce qui est nécessaire à la compilation. _________________________________________________________ 3.1.2. Exemple Un exemple d'utilisation d'autoconf : $ ./configure loading cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for main in -lX11... yes checking for main in -lXpm... yes checking for main in -lguile... yes checking for main in -lm... yes checking for main in -lncurses... yes checking how to run the C preprocessor... gcc -E checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for ANSI C header files... yes checking for unistd.h... yes checking for working const... yes updating cache ./config.cache creating ./config.status creating lib/Makefile creating src/Makefile creating Makefile Si on veut avoir un peu plus de contrôle sur ce que génère configure, on peut lui passer des options via la ligne de commande ou des variables d'environnement. Exemple : ./configure --with-gcc --prefix=/opt/GNU ou encore (sous bash) : export CC=`which gcc` export CFLAGS=-O2 ./configure --with-gcc _________________________________________________________ 3.1.3. Et si... ça ne marche pas ? Typiquement, il s'agit d'une erreur de type "configure: error: Cannot find library guile" (95% des erreurs du script configure). Clairement, le script configure n'a pas réussi à trouver une librairie (dans notre exemple, la librairie guile). Le principe est que le script configure compile un petit programme de test qui utilise cette librairie. S'il n'arrive pas à compiler ce programme, c'est qu'il n'arrivera pas à compiler le logiciel. D'où une erreur. 1. Regardez d'où vient l'erreur rencontrée en regardant la fin du fichier config.log, qui contient une trace de toutes les étapes de la configuration. Le compilateur C est généralement assez explicite dans ses messages d'erreur. Cela vous aidera pour résoudre le problème. 2. Vérifiez que la librairie en question est bien installée. Si ce n'est pas le cas, installez-la (à partir des sources ou d'un binaire précompilé) et exécutez à nouveau configure. Une méthode efficace pour le vérifier est de rechercher le fichier matérialisant la librairie, qui est invariablement libnom.so. Par exemple, $ find / -name libguile* ou encore : $ locate libguile 3. Vérifiez qu'elle est accessible au compilateur. C'est à dire que la librairie est bien située dans un répertoire parmi : /usr/lib, /lib, /usr/X11R6/lib (ou parmi ceux spécifiés par la la variable d'environnement LD_LIBRARY_PATH, voir la partie LD_LIBRARY_PATH de la section Et si ça ne fonctionne pas ?"). Vérifiez que ce fichier est bien une librairie en faisant un "file libguile.so". 4. Vérifiez que les fichiers d'en-tête correspondant à la librairie sont bien installés à la bonne place (généralement /usr/include ou /usr/local/include ou /usr/X11R6/include. Si vous ne savez pas de quels fichiers d'en-tête vous avez besoin, vérifiez que vous avez bien installé la version de développement de la librairie nécessaire (par exemple, sous Debian GNU/Linux : libgtk-dev au lieu de libgtk). La version de développement de la bibliothèque est livrée avec les fichiers include nécessaires à la compilation d'un logiciel utilisant cette librairie. 5. Vérifiez que vous avez assez de place disque (le script configure a besoin d'un peu de place pour des fichiers temporaires). Utilisez df -k pour visualiser les partitions de votre système, et ne vous préoccupez que des partitions pleines ou presque. Si vous ne comprenez pas le message d'erreur stocké dans le fichier config.log, n'hésitez pas à demander aide et assistance à la communauté du logiciel libre (voir la section Support technique). De plus, méfiez vous si configure répond 100% de No ou s'il répond No alors que vous êtes certain qu'une bibliothèque existe (par exemple il serait très étrange qu'il n'existe pas au moins une librairie curses !). Dans ce cas, on est probablement en présence d'une variable LD_LIBRARY_PATH mal positionnée ! _________________________________________________________ 3.2. Imake Imake permet de configurer un logiciel libre en créant un fichier Makefile à partir de règles simples. Ces règles déterminent quels fichiers ont besoin d'être compilés pour construire le binaire, et Imake génère le Makefile correspondant. Ces règles sont spécifiées dans un fichier appelé Imakefile. Là où Imake prend tout son intérêt, c'est qu'il utilise des informations dépendantes du site (de l'architecture de la machine). C'est assez pratique dans le cas d'applications utilisant XWindow. Mais Imake est utilisé dans le cas de beaucoup d'autres applications. L'utilisation la plus simple de Imake est de se rendre dans le répertoire principal de l'archive décompactée, et ensuite d'exécuter le script xmkmf qui fera appel au programme imake : $ xmkmf -a imake -DUseInstalled -I/usr/X11R6/lib/X11/config make Makefiles Si le site est mal installé (çela arrive souvent avec Solaris par exemple), recompiler et installer X11R6 ! Je crois qu'il y a un moyen de ne récupérer et recompiler qu'Imake, mais par manque de temps je n'ai pas cherché, donc je suis preneur ! _________________________________________________________ 3.3. Scripts shells divers Lisez le fichier INSTALL ou README pour de plus amples informations. Généralement, il va vous falloir exécuter un fichier de type install.sh ou configure.sh. Après, soit le script d'installation sera silencieux (et déterminera tout seul ce dont il a besoin), soit il vous demandera des informations sur votre système (par exemple des chemins). Si vous n'arrivez pas à déterminer le fichier que vous devez exécuter, vous pouvez (sous bash) taper "./", et ensuite taper deux fois la touche TAB (tabulation). bash complètera automatiquement par un éventuel fichier exécutable du répertoire (donc un éventuel script de configuration). Dans le cas où plusieurs fichiers sont exécutables, il vous donnera une liste. Il ne vous reste plus qu'à choisir le bon. Un cas particulier est l'installation de modules perl (mais pas seulement). L'installation de tels modules se fait par l'exécution d'un script de configuration lui-même en perl. La commande à effectuer est généralement : $ perl Makefile.PL _________________________________________________________ 3.4. Autres alternatives Certaines distributions de logiciels libres sont mal organisées, surtout lors des premières phases de développement (mais l'utilisateur est prévenu !). Elles nécessitent parfois de retoucher "à la main" les fichiers de configuration. Généralement, ces fichiers sont un fichier Makefile (voir la section Make), et un fichier config.h (ce nom n'est qu'une convention). Je ne recommande ces manipulations qu'à des utilisateurs sachant ce qu'ils font. C'est un travail qui nécessite des connaissances réelles et une motivation nécessaire pour réussir. Mais c'est en forgeant qu'on devient forgeron. _________________________________________________________ 4. Compilation Maintenant que le logiciel est correctement configuré, il ne reste plus qu'à le compiler. C'est une étape qui est généralement très simple à effectuer, et qui ne pose généralement pas de problèmes majeurs. _________________________________________________________ 4.1. Make L'outil préféré de la communauté du logiciel libre pour compiler des sources est make. L'intérêt de make est double : * il permet au développeur de gagner du temps, car il présente des avantages permettant de gérer la compilation de son projet de manière efficace, * il permet à l'utilisateur final de compiler et d'installer le logiciel en quelques lignes de commande, et ceci sans connaissance préalable du développement. Les actions à exécuter pour arriver à une version compilée des sources sont stockées dans un fichier nommé habituellement Makefile ou GNUMakefile. En fait, lorsque make est invoqué il lit ce fichier s'il existe dans le répertoire courant. Si ce n'est pas le cas, il est possible de spécifier ce fichier en passant l'option -f à make. _________________________________________________________ 4.2. Règles make fonctionne selon un système de dépendances. C'est à dire que pour qu'un binaire soit compilé (cible), un certain nombre d'étapes doivent être accomplies (dépendances). Par exemple, pour créer le binaire glloq, on a besoin de compiler les fichiers objets (fichiers intermédiaires de la compilation) main.o et init.o, puis de les lier. Ces fichiers objets sont eux aussi des cibles, dont les dépendances sont les fichiers sources. Ceci n'est qu'une introduction minimale pour survivre dans le monde impitoyable de make. Si vous voulez en savoir plus, je vous conseille de vous rendre sur le site d'APRIL à l'url http://www.april.org/groupes/doc/ pour une documentation à peine plus détaillée sur make. Pour une documentation exhaustive, voir Managing Projects with Make, seconde édition, chez O'Reilly, d'Andrew Oram et Steve Talbott. _________________________________________________________ 4.3. Go, go, go !!! Généralement, l'utilisation de make obéit à plusieurs conventions. Par exemple : 1. make sans argument exécute la compilation seule du programme, sans installation 2. make install compile le programme (mais pas toujours), et assure l'installation des fichiers nécessaires au bon endroit sur le système de fichiers. Certains fichiers ne sont pas toujours installés correctement (man, info), il faut alors les copier à la main. Dans certains cas, il faut effectuer une nouvelle fois un make install dans des sous-répertoires. Généralement il s'agit de modules développés par une tierce personne). 3. make clean efface tous les fichiers temporaires créés par la compilation, et y compris le fichier exécutable dans la majorité des cas. La première étape est de compiler le programme, et donc de faire (exemple fictif) : $ make gcc -c glloq.c -o glloq.o gcc -c init.c -o init.o gcc -c main.c -o main.o gcc -lgtk -lgdk -lglib -lXext -lX11 -lm glloq.o init.o main.o -o glloq Parfait, le binaire est compilé correctement. Nous sommes prêts à passer à l'étape suivante, qui est l'installation des fichiers de la distribution (binaire, fichiers de données, etc...). Voir la section Installation. _________________________________________________________ 4.4. Explications Si vous avez la curiosité de regarder ce qu'il y a dans le fichier Makefile, vous y trouverez des commandes connues (rm, mv, cp, ...), mais aussi des chaînes de caractères étranges, de la forme $(CFLAGS). Il s'agit de variables, c'est à dire de chaînes qui sont fixées généralement au début du Makefile, et qui seront ensuite remplacées par la valeur qui leur a été associée. C'est assez utile pour utiliser plusieurs fois de suite les mêmes options de compilation. Par exemple, pour afficher la chaîne "toto" à l'écran en faisant un "make all": TEST = toto all: echo $(TEST) La plupart du temps, les variables suivantes sont définies : * CC : il s'agit du compilateur que l'on va utiliser. Généralement il s'agit de gcc, mais sur la plupart des systèmes libres, le compilateur par défaut utilisé par make (soit cc) est un synonyme de gcc. Dans le doute, n'hésitez pas à mettre ici gcc. * LD : il s'agit du programme utilisé parfois pour assurer la phase finale de la compilation (voir la section Les quatre phases de la compilation"). Par défaut, la valeur est ld. * CFLAGS : ce sont les arguments supplémentaires qu'on passera au compilateur lors des premières phases de la compilation. Parmi ceux-ci : + -Ichemin : spécifie au compilateur où chercher des fichiers d'en-tête supplémentaires (ex: -I/usr/X11R6/include permet d'inclure les fichiers d'en-tête se situant dans /usr/X11R6/include) + -Dsymbole : définit un symbole supplémentaire, utile dans certains programmes qui se compilent différemment selon les symboles définis (ex: utilise le fichier string.h si HAVE_STRING_H est défini) On trouve souvent des lignes de compilation de la forme : $(CC) $(CFLAGS) -c toto.c -o toto.o * LDFLAGS (ou LFLAGS): ce sont les arguments passés lors de la dernière phase de la compilation. Parmi ceux ci : + -Lchemin : spécifie un chemin supplémentaire où chercher des bibliothèques (ex: -L/usr/X11R6/lib) + -lbibliothèque : spécifie une bibliothèque supplémentaire à utiliser lors de la dernière phase de compilation _________________________________________________________ 4.5. Et si ça ne fonctionne pas ? Pas de panique, ça arrive à tout le monde. Parmi les causes les plus communes : 1. glloq.c:16: decl.h: No such file or directory Le compilateur n'a pas réussi à trouver le fichier d'en-tête correspondant. Et pourtant, la configuration du logiciel aurait dû anticiper cette erreur. Comment résoudre ce problème : a. vérifiez que l'en-tête existe vraiment sur le disque dans un des répertoires parmi /usr/include, /usr/local/include, /usr/X11R6/include ou un sous-répertoire. Si ce n'est pas le cas, recherchez le sur tout le disque (find ou locate), et si vous ne le trouvez toujours pas, alors vérifiez à deux fois que vous avez installé la librairie correspondant à cet en-tête. Vous trouverez des exemples des commandes find et locate dans leurs pages man respectives. b. vérifiez que l'en-tête est bien accessible en lecture (faites un more chemin/fichier.h pour le tester) c. s'il se trouve dans un répertoire comme /usr/local/include ou /usr/X11R6/include, il est parfois nécessaire de passer un argument supplémentaire au compilateur. Ouvrez le fichier Makefile correspondant (attention à ouvrir le bon, celui qui se trouve dans le répertoire où la compilation échoue[3]) avec votre éditeur de textes favori (Emacs, vi, ...). Recherchez la ligne fautive, et rajoutez la chaîne de caractères "-I/chemin"(où chemin est le chemin où se trouve l'en-tête en question juste après l'appel du compilateur (gcc, ou parfois $(CC)). Si vous ne savez pas où rajouter cette option, rajoutez-la au début du fichier, à la fin de la ligne "CFLAGS = quelquechose" ou de la ligne "CC = quelquechose" d. relancez make, et si ça ne marche toujours pas, vérifiez que cette option (cf point précédent) est bien rajoutée à la compilation sur la ligne fautive e. si ça ne marche toujours pas, demandez à votre gourou local ou faites appel à la communauté du logiciel libre pour résoudre votre problème (voir la section Support technique) 2. glloq.c:28: `struct toto' undeclared (first use this function) Les structures sont des types de données spéciaux, que tous les programmes utilisent. Beaucoup sont définies par le système dans les fichiers d'en-tête. Ce qui signifie que le problème vient certainement d'un en-tête manquant ou mal utilisé. La marche à suivre pour résoudre le problème est : a. de tenter de véfifier si la structure en question est une structure définie dans le programme ou par le système. Une solution est d'utiliser la commande grep afin de vérifier si la structure est définie dans un des fichiers d'en-tête. Par exemple, après vous etre rendu dans la racine de la distribution : $ find . -name '*.h'| xargs grep 'struct toto' | more Il est possible que plusieurs dizaines de lignes apparaissent à l'écran (à chaque fois qu'une fonction utilisant ce type de structure est définie par exemple). Si elle existe, repérez la ligne où la structure est définie en regardant le fichier en-tête obtenu par l'utilisation de grep. La définition d'une structure est : struct toto { >contenu de la structure< }; Vérifiez si cela correspond avec ce que vous avez. Le cas échéant, c'est que ce fichier d'en-tête n'est pas inclus dans le fichier .c fautif. Deux solutions s'offrent à vous : i. rajoutez la ligne #include "nomdufichier.h" au début du fichier .c fautif ii. ou copiez-collez la définition de la structure au début de ce fichier (ce qui n'est pas très propre, mais ça a le mérite de marcher généralement) 3. si ce n'est pas le cas, faites la même chose sur les fichiers d'en-tête du système (qui se trouvent sur /usr/include, /usr/X11R6/include, ou /usr/local/include généralement. Mais cette fois ci, utilisez la ligne #include 4. si cette structure n'existe toujours pas, essayez de trouver dans quelle bibliothèque (au sens ensemble de fonctions regroupées dans un seul package) elle devrait être définie (regardez dans le fichier INSTALL ou README quelles sont les bibliothèques utilisées par le programme et leur version nécessaire). Si la version dont le programme besoin n'est pas celle installée sur votre système, alors effectuez une mise à jour de cette bibliothèque. 5. si ça ne marche toujours pas, vérifiez que le programme fonctionne bien correctement sur votre architecture (certains programmes n'ont pas encore été portés sur tous les Unix). Vérifiez aussi que vous avez bien configuré le programme (au moment du configure par exemple) pour votre architecture. parse error C'est un problème assez compliqué à résoudre, car généralement il s'agit d'une erreur que le compilateur rencontre plus haut, mais qui ne se manifeste qu'à une certaine ligne. Parfois, il s'agit simplement d'un type de donnée qui n'est pas défini. Si vous rencontrez un message d'erreur de type : main.c:1: parse error before `glloq_t main.c:1: warning: data definition has no type or storage class alors, le problème est que le type glloq_t n'est pas défini. La solution pour résoudre ce problème est à peu près la même que pour le problème précédent. (Remarque: il peut y avoir un parse error dans les vieilles librairies curses si ma mémoire est bonne). no space left on device Le problème est assez simple à régler : la place sur le disque est insuffisante pour générer un binaire à partir du fichier source. La solution consiste à libérer de la place dans la partition abritant le répertoire d'installation (supprimez les fichiers temporaires ou les sources, désinstallez les programmes dont vous ne vous servez pas). Si vous l'avez décompacté dans /tmp, faites-le plutôt dans /usr/local/src ce qui évite de saturer inutilement la partition /tmp. Vérifiez de plus que vous n'avez pas de fichiers core sur le disque. Si oui, effacez les ou faites les effacer s'ils appartiennent à un autre utilisateur. /usr/bin/ld: cannot open -lglloq: No such file or directory Clairement, le programme ld (utilisé par gcc lors de la dernière phase de la compilation) n'a pas réussi à trouver une bibliothèque. Il faut savoir que pour inclure une bibliothèque, ld va chercher un fichier dont le est passé par l'argument -lbibliothèque. Ce fichier est libbibliothèque.so. Si ld n'arrive pas à le trouver, alors il produit ce message d'erreur. Pour résoudre ce problème, procédons par étapes : a. Vérifions que ce fichier existe bien sur le disque dur, en utilisant la commande locate. Généralement, les bibliothèques graphiques se trouvent dans /usr/X11R6/lib. Par exemple : $ locate libglloq Si cela ne donne rien, vous pouvez faire une recherche avec find (ex: "find /usr -name libglloq.so*"). Si vous ne trouvez pas la bibliothèque, alors il vous reste à l'installer. b. Une fois la bibliothèque localisée, vérifions que cette bibliothèque est bien accessible pour ld : le fichier /etc/ld.conf spécifie où trouver ces librairies. Rajoutez le répertoire incriminé à la fin (il est possible que vous ayez à rebooter la machine pour que cela soit pris en compte). Il est aussi possible de rajouter ce répertoire en modifiant le contenu de la variable d'environnement LD_LIBRARY_PATH. Par exemple, en imaginant que le répertoire à ajouter est /usr/X11R6/lib : $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/X11R6/lib c. Si celà ne fontionne toujours pas, vérifiez que la bibliothèque incriminée est bien au format ELF (avec la commande file). Si c'est un lien symbolique, vérifiez que ce lien est correct et ne pointe pas vers un fichier inexistant (par exemple, avec un nm libglloq.so). Les permissions peuvent de plus être incorrectes (si vous utilisez un compte autre que root et que la librairie est protégée en lecture par exemple). glloq.c(.text+0x34): undefined reference to `glloq_init' Aïe ! Aïe ! Aïe ! Pourquoi cette noirceur ? Il s'agit d'un symbole non résolu lors de la dernière phase de la compilation. Généralement, il s'agit d'un problème de bibliothèque. A priori, plusieurs causes possibles : a. la première chose à faire est de savoir si le symbole est censé être présent dans une bibliothèque. Par exemple, s'il s'agit d'un symbole commençant par gtk, il appartient très certainement à la bibliothèque gtk. Si le nom de la bibliothèque est difficilement identifiable (zorglub_gloubiboulga), il est possible de lister les symboles d'une bibliothèque avec la commande nm. Par exemple, $ nm libglloq.so 0000000000109df0 d glloq_message_func 000000000010a984 b glloq_msg 0000000000008a58 t glloq_nearest_pow 0000000000109dd8 d glloq_free_list 0000000000109cf8 d glloq_mem_chunk Rajouter l'option -o à nm permet de plus d'afficher le nom de la bibliothèque sur chaque ligne, ce qui simplifie les recherches. Imaginons que nous cherchions le symbole bulgroz_max, une solution de barbare est d'effectuer une recherche de ce genre : $ nm /usr/lib/lib*.so | grep bulgroz_max $ nm /usr/X11R6/lib/lib*.so | grep bulgroz_max $ nm /usr/local/lib/lib*.so | grep bulgroz_max /usr/local/lib/libzorglub.so:000000000004d848 T bulgroz_max Formidable ! Le symbole bulgroz_max est défini dans la bibliothèque zorglub (la lettre majuscule T se trouve devant son nom). Il suffit de rajouter la chaîne -lzorglub dans la ligne de compilation en éditant le fichier Makefile : rajoutez-la à la fin de la ligne où LDFLAGS ou LFGLAGS (ou au pire CC) sont définis, ou alors sur la ligne responsable de la création du fichier binaire final b. la compilation se fait avec une version de la librairie qui n'est pas la même que celle prévue pour le logiciel. Lisez le fichier README ou INSTALL de la distribution pour savoir pour quelle version de la librairie doit être utilisée c. tous les fichiers objets de la distribution ne sont pas correctement liés. Il manque le fichier dans lequel est définie cette fonction. Faites un "nm -o *.o" pour le savoir et rajoutez le fichier .o correspondant sur la ligne de compilation s'il est manquant. d. la fonction ou variable incriminée est peut-être fantaisiste. Essayez de la supprimer : éditez le fichier source incriminé (son nom est spécifié au début du message d'erreur). C'est une solution désespérée, qui va avoir pour conséquence un fonctionnement très probablement anarchique du programme (segfault au démarrage, etc.) Segmentation fault (core dumped) Parfois, le compilateur plante lamentablement, et produit ce message d'erreur. Je n'ai pas d'autre conseil que de vous demander d'installer une version plus récente de votre compilateur (il me semble que la version 2.8.x de gcc est particulièrement buggée) plus de place sur /tmp La compilation, a besoin d'espace temporaire de travail lors de ses différentes étapes ; si elle ne l'a pas, elle échoue. Il faut donc faire du ménage, mais attention car certains fichiers risquent de planter des programmes qui s'exécutent (serveur X, pipes...) s'ils sont supprimés. Il faut donc bien savoir ce que l'on fait ! Si /tmp fait partie d'une partition qui ne contient pas que lui (par exemple la racine), recherchez et supprimez d'éventuels fichiers core. make/configure en boucle Il s'agit généralement d'un problème d'heure sur votre système. make a en effet besoin de connaître la date ainsi que celle des fichiers qu'il vérifie. Il compare les dates des fichiers et utilise le résultat pour savoir si la cible est plus récente que la dépendance. Il se peut que des problèmes de date ammène make à se reconstruire sans fin (ou de construire et reconstruire un arborescence en boucle). Dans ce cas là, l'utilisation de la commande touch (qui a pour conséquence de mettre à l'heure courante les fichiers passés en argument) permet de résoudre le problème dans la plupart des cas. Par exemple : $ touch * Ou encore plus barbare (mais efficace) : $ find . | xargs touch _________________________________________________________ 5. Installation 5.1. Avec make Maintenant que tout est compilé, il vous reste a copier les fichiers produits vers un endroit adéquat (généralement dans un des sous-répertoires de /usr/local). make permet généralement d'assurer ce travail. Un cible spéciale est la cible install. Très logiquement, utiliser "make install" permet d'installer les fichiers nécessaires. Généralement, la procédure est décrite dans les fichiers INSTALL ou README. Mais parfois, l'auteur a oublié d'en prévoir une. Dans ce cas, il va falloir tout installer à la main. Copiez alors : * les exécutables (programmes) dans le répertoire /usr/local/bin * les librairies (fichiers lib*.so) dans le répertoire /usr/local/lib * les fichiers d'en-tête (fichiers *.h) dans le répertoire /usr/local/include (attention à ne pas écraser les fichiers originaux) * le fichiers de données vont généralement dans /usr/local/share. Si vous ne connaissez pas la procédure d'installation, vous pouvez essayer de lancer le programme sans copier les fichiers de données, et de les mettre au bon endroit lorsqu'il vous les demande (message d'erreur du type "Cannot open /usr/local/share/glloq/data.db") * la documentation est un peu a part : + les fichiers man se placent dans un des sous-répertoires de /usr/local/man. Généralement, ces fichiers sont au format groff, et ont pour extension un chiffre. Leur nom est celui d'une commande (par exemple echo.1). Si le chiffre est n, copiez ce fichier dans /usr/local/man/mann. + les fichiers info se placent dans le répertoire /usr/info ou /usr/local/info Et voilà, c'est fini ! Félicitations ! Vous êtes maintenant fin prêt à recompiler votre système d'exploitation tout entier. _________________________________________________________ 5.2. Problèmes Si vous venez d'installer un programme libre, par exemple GNU tar et si quand vous l'exécutez ce n'est pas lui qui est appelé ou s'il ne fonctionne pas comme quand vous le testiez directement à partir du répertoire src, c'est un problème de PATH qui trouve le programme dans un répertoire bien avant celui où vous avez installé le nouveau logiciel. Vérifiez en exécutant "type -aprogramme". La solution est de mettre le répertoire d'installation plus haut dans le PATH, et/ou supprimer/renommer les fichiers qui s'exécutent sans qu'on le veuille, et/ou renommer votre nouveau programme (en gtar dans cet exemple) de sorte qu'il n'y ait pas confusion. Ou alors faire un alias si le shell le permet (par exemple dire que tar c'est /usr/local/bin/gtar). _________________________________________________________ 6. Support 6.1. Documentation Plusieurs sources de documentation : * les HOWTO, petites documentations sur un sujet précis (généralement, pas trop proche de ce qui nous intéresse ici, mais parfois utiles). Voir sur votre disque dans /usr/doc/HOWTO (pas toujours, parfois ils sont mis ailleurs), ou alors sur http://www.freenix.fr pour une version française des HOWTO, * les pages man. Faire un "man commande" pour de la documentation sur le commande commande, * la littérature spécialisée. Plusieurs grands éditeurs commencent à sortir des livres sur les systèmes libres (plus spécialement sur GNU/Linux). C'est souvent utile si vous débutez et que vous ne comprenez pas les termes de cette documentation. _________________________________________________________ 6.2. Support technique Si vous avez acheté une distribution "officielle" (par exemple RedHat GNU/Linux), vous pouvez demander au support technique des informations sur votre système. J'imagine que le support technique a autre chose à faire que d'aider tous les utilisateurs à installer des logiciels supplémentaires, mais certains proposent une aide à l'installation de x jours. Peut-être peuvent ils passer quelque temps sur le problème de compilation ? Vous pouvez sinon compter sur l'aide de la communauté du logiciel libre : * les newsgroups (forums de discussions sur Usenet) fr.comp.os.linux.* permettent de répondre à toutes questions concernant GNU/Linux. fr.comp.os.bsd a pour sujet les systèmes BSD. Il doit exister d'autres forums dédiés a d'autres UNIX. * les mêmes newsgroups existent en version anglaise. Supprimez la chaîne fr de leur nom. * plusieurs associations ou groupes d'enthousiastes du logiciel libre proposent un support bénévole. Par exemple le GCU[4] ou linuxfr. * plusieurs channels irc permettent une assistance en temps réel (mais en aveugle) par des gourous. Voir par exemple le channel #linux sur la plupart des réseaux d'IRC, ou #linuxhelp sur IRCNET. * en dernier recours, demander à l'auteur du logiciel (s'il a mentionné son nom et son adresse électronique dans un fichier de la distribution) si vous êtes sûr d'avoir identifié un bug (qui peut n'être dû qu'à votre architecture, mais après tout, un logiciel libre est censé être portable). _________________________________________________________ 6.3. Comment trouver des logiciels libres Pour trouver des logiciels libres, de nombreux pointeurs peuvent vous aider : * l'énorme site FTP sunsite.unc.edu ou l'un de ses miroirs * les sites webs suivants effectuent un catalogue de nombreux logiciels libres utilisables sous plates-formes UNIX (mais pas seulement, aussi des des logiciels propriétaires) : + http://www.freshmeat.net est sans doute le site le plus complet, + http://www.linux-france.org contient de nombreux pointeurs vers des logiciels fonctionnant sous GNU/Linux. La plupart fonctionnent bien sûr sur les autres plates-formes UNIX libres, + http://www.gnu.org/software/ pour une liste exhaustive de tous les logiciels GNU. Bien sûr, tous sont libres et sous GPL. * vous pouvez de plus effectuer une recherche sur des moteurs comme http://www.altavista.com et effectuer une requête de type : +logiciel +download ou "download logiciel". _________________________________________________________ 7. Remerciements * Relectures et commentaires désobligeants (et par ordre alphabétique) : Mathieu Bois, Xavier Renaut et Kamel Sehil * Béta-testing : Laurent Bassaler _________________________________________________________ 8. Copyright Copyright (c) 1999 Benjamin Drieu, association APRIL. This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This work is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this work; see the file COPYING. If not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Notes [1] Ce n'est pas tout à fait vrai car certains logiciels propriétaires fournissent aussi leur code source. Mais à la différence d'un logiciel libre, l'utilisateur final n'a pas le droit de l'utiliser de la manière qu'il désire. [2] Un proverbe venant du monde BSD dit : never trust a software you don't have the sources (ne faites pas confiance en un programme dont vous n'avez pas les sources) [3] analysez le message d'erreur renvoyé par make. Normalement, les dernières lignes devraient contenir un répertoire (un message de la forme "make[1]: Leaving directory `/home/benj/Projet/Pouet'"). Repérez celle dont le numéro est le plus grand. Pour vérifier qu'il s'agit bien du bon, rendez vous dans ce répertoire, et exécutez make à nouveau pour obtenir la même erreur [4] tout le monde a oublié la signification de ce sigle depuis la nuit des temps. Voir http://www.cie.fr/gcu/.