Page suivante Page précédente Table des matières 2. Installation 2.1 Prérequis Le but de cette mise à jour est de vous fournir un système qui puisse compiler et exécuter aussi bien les programmes basés sur a.out que ELF, en s'assurant que chaque type de programme soit capable de trouver la version appropriée des bibliothèques partagées. Il apparaît aisément que cela demande plus de travail que simplement chercher dans /lib, dans /usr/lib ou n'importe où ailleurs selon le chemin de recherche indiqué dans la compilation, stratégie dont certains autres systèmes se satisfont. Le travail nécessaire est centralisé au niveau d'un chargeur dynamique qui existe en un seul, ou deux, endroit du système. Pour les programmes a.out, il est appelé /lib/ld.so et, pour les programmes ELF, on fait appel à /lib/ld-linux.so.1. Le compilateur et l'éditeur de liens n'encodent pas les chemins absolus des librairies dans les programmes qu'ils produisent ; ils fournissent en effet le nom de la librairie et son chemin absolu au chargeur dynamique approprié et se contentent de ça pour apparier le nom de la bibliothèque au chemin correspondant lors de l'exécution. Cela a une conséquence d'importance : les bibliothèques peuvent être déplacées dans d'autres répertoires sans recompiler le programme dès lors que ld.so (ou ld-linux.so.1 selon le cas) a été informé de chercher dans le nouveau répert! ! ! ! ! ! oire. C'est une fonctionnalité essentielle pour l'échange de répertoires qui va suivre. Le corollaire de ce qui précède est bien sûr que toute tentative d'effacer ou de déplacer ld.so ou ld-linux.so.1 pourrait provoquer le plantage de tout programme dynamiquement lié sur le système. C'est généralement vu comme une Mauvaise Chose. Le schéma général est alors de mettre tout ce qui concerne le développement ELF (compilateurs, bibliothèques et fichiers d'inclusions) dans /usr/{bin,lib,include} et de mettre ce qui concerne a.out dans /usr/i486-linuxaout/{bin, lib, include}. Le fichier /etc/ld.so.conf est la liste de tous les endroits du système où l'on s'attend à trouver les bibliothèques et ldconfig est suffisamment malin pour distinguer les versions ELF des versions a.out. Il y a néanmoins quelques exceptions quant au placement de la bibliothèque : Certains vieux programmes ont été compilés sans l'utilisation de ld.so. Ceux-ci cesseraient alors de fonctionner si leurs librairies devaient être déplacées. Ainsi libc.so* et libm.so* doivent rester où ils sont dans /lib et les versions ELF ont vu leurs numéros majeurs mis à jour afin qu'ils n'écrasent pas les versions a.out. Les vieilles bibliothèques X (avant la version 6) feraient mieux de rester où elles sont alors que les plus récentes (libX*so.6) doivent être déplacées. Déplacer les anciennes bloquera xview et ne pas déplacer les nouvelles fera qu'elles seront écrasées lors de l'installation des bibliothèques ELF. Si vous avez des programmes non ld.so qui nécessitent des bibliothèques autre que celles citées ci-dessus (si vous savez de quels programmes il s'agit, vous pouvez exécuter ldd sur ceux-ci afin de déterminer quelles bibliothèques leurs sont nécessaires avant de les bloquer), deux solutions s'offrent à vous. La première est d'extraire la librairie ELF dans un répertoire temporaire, de voir si votre précieuse librairie va être écrasée et, si le cas se présente, de déplacer la version ELF de la bibliothèque dans, disons, /usr/i486-linux/lib en lieu et place de /lib.Assurez vous que ld.so.conf contient /usr/i486-linux/lib et exécutez ldconfig puis n'y pensez plus. La seconde est de recompiler ou d'obtenir une nouvelle version du programme incriminé. Cela n'est pas une mauvaise idée, si c'est possibl! ! ! ! ! ! e. Si vous avez /usr et / sur des partitions différentes, toutes les bibliothèques que vous déplacerez de /lib devront se retrouver autre part sur le disque racine et pas sur /usr. J'ai utilisé /lib-aout pour les instructions qui suivent. 2.2 Avant de commencer : notes et mises en gardes Il va vous falloir tourner sous un noyau postérieur au 1.1.52 avec support des fichiers exécutables ELF. Le 1.2.13 ainsi que le 2.0.30 font l'affaire ainsi que la plupart des noyaux de la série 1.3 bien que l'intérêt de tourner sous des anciens noyaux expérimentaux est maintenant discutable avec l'arrivée du 2.0. Il est recommandé de se munir d'une disquette d'amorçage Linux telle que la disquette de sauvetage de Slackware. Vous n'en aurez probablement pas besoin mais si vous n'en avez pas et que vous en ayez besoin, vous serez dans le pétrin. Dans le même esprit "il vaut mieux prévenir que guérir", des copies statiquement liées de mv, ln ou d'autres commandes de manipulation de fichier pourraient vous aider à sortir des situations périlleuses dans lesquelles vous pourriez vous mettre. Si vous avez suivi le développement de ELF depuis le début ou si vous avez installé certaines versions de Slackware, vos bibliothèques ELF peuvent être dans /lib/elf. Les applications que vous avez compilées avec celles-ci doivent être recompilées avant d'effacer ce répertoire. /lib/elf n'est pas nécessaire! La plupart des installations Linux modernes se sont rejointes sur l'adoption du système de fichiers standard "FSSTND" mais il y en a sans nul doute quelques unes qui sont en retard. Si vous voyez des références à /sbin/quelque chose et que vous n'avez pas de répertoire /sbin/, vous trouverez probablement le programme en question dans /bin ou /etc/. Ceci est particulièrement important quand vous installez de nouveaux programmes: si /etc est placé avant /sbin dans le chemin de recherche, vous obtiendrez des erreurs parce que vous ferez appel aux anciennes versions alors que vous n'auriez pas dû. C'est une bonne idée de choisir un moment où nul n'utilise l'ordinateur ou de le lancer en mode mono-utilisateur. Relancez-le d'une disquette d'amorçage de manière à ne pas rester bloqué, même si, pour ma part, j'aime bien jouer avec le feu... 2.3 Notions Tout ce qui est décrit ci-après par "sur tsx-11" peut être trouvé à ftp://tsx-11.mit.edu/pub/linux/packages/GCC/, ftp://sunsite.unc.edu/pub/Linux/GCC/, et d'autres sites miroir (NdT: comme ftp://ftp.lip6.fr/pub/linux/ pour la France). Veuillez consulter le site miroir le plus proche de chez vous plutôt que les sites généraux dès que cela est possible. Cela ira plus vite, pour vous et pour les autres. Ces paquetages (que ce soit la version listée ou une plus récente) sont requis. Pensez également à télécharger les notes concernant votre version pour chacun d'entre eux: elles sont de la forme release.nom_du_paquetage. Cela est particulièrement vrai pour les versions plus récentes que celles présentées ici (l'installation a pu changer). Même si vous avez pour habitude de compiler à partir des sources, je vous recommande de prendre les versions binaires quand je l'indique à moins que vous n'ayez réellement plus besoin de vos cheveux. La plupart d'entre eux ne sont pas prévus pour la compilation sur un système mixte et vous vous exposez à de graves ennuis si vous essayez. Les essentiels ld.so-1.7.14.tar.gz --- le nouveau générateur de liens dynamiques. Il contient à la fois les sources et les versions compilées. Notez que la version à venir nécessitera une prise en charge d'ELF même pour les exécutables a.out; si vous récupérez la version 1.8.1 ou plus récente en lieu et place de la version mentionnée, vérifiez que votre noyau a été compilé avec l'option support d'ELF avant de l'installer. libc-5.3.12.bin.tar.gz --- les images partagées pour ELF des bibliothèques C et de maths, plus les bibliothèques correspondantes en statique et les fichiers include nécessaires pour compiler les programmes. Si vous voulez le code source, préparez vous alors à attendre pendant des heures pendant la compilation, si jamais il se compile (à moins que vous n'ayez déjà un système ELF). gcc-2.7.2.bin.tar.gz --- le paquetage du compilateur C ELF qui comprend également un compilateur C a.out qui tient compte de la nouvelle disposition des répertoires. Si vous vous voulez compiler gcc vous même (ce que vous trouverez certainement plus simple si vous utilisez déjà ELF), il est recommandé d'appliquer gcc-2.7.2-linux.diff.gz aux sources GNU avant de le faire. binutils-2.6.0.12.bin.tar.gz --- les utilitaires GNU en version Linux. Ce sont des programmes tels que gas, ld, strings et ainsi de suite, la plupart d'entre eux étant requis pour l'exécution du compilateur C. Notez bien que les binutils GNU "vanilla" (à savoir ceux de prep.ai.mit.edu) ne sont pas un substitut acceptable. Si vous voulez réellment les compiler vous même, faites appel au paquetage modifié pour Linux binutils-2.6.0.12.tar.gz plutôt qu'à la version GNU. ncurses-1.9.9e.tar.gz --- c'est une bibliothèque curses compatible SVR4, c'est donc la bibliothèque considérée comme standard concernant curses sous Linux. On peut en obtenir le code source sur des sites GNU tels que ftp://prep.ai.mit.edu/gnu/ ou encore sur ftp://ftp.netcom.com/pub/zm/zmbenhal. Il y a aussi une version compilée du paquetage sur tsx-11. Avant que vous installiez cela, vous disposerez d'un système de développement ELF pleinement fonctionnel, je vous recommande donc le paquetage source si vous avez la moindre once de puissance pour la compilation. gdbm-1.7.3.tar.gz est un ensemble de routines de base de donnés qui fait appel au hachage et qui fonctionne de manière comparable aux routines dbm et ndbm standards d'UNIX. Le source est récupérable sur ftp://prep.ai.mit.edu/gnu/ et vous aurez besoin du patch ftp://ftp.uk.linux.org/pub/Linux/libc/non-core/gdbm.patch pour en obtenir des bibliothèques partagées. Le patch corrige également quelques petites choses (une coquille dans le Makefile et une prédisposition à utiliser une mauvaise option de protection des fichiers). Autres Il y a d'autres bibliothèques et fichiers qui ne sont pas essentiels mais que vous voudrez probablement avoir de toute façon. Cette liste comporte seulement des paquetages qui nécessitent d'être mis à jour pour fonctionner de manière utile vis-à-vis d'ELF. Plus loin dans ce document, une nouvelle liste indique les programmes qui continueront à fonctionner mais qu'il vous faudra mettre à jour pour les recompiler en ELF. Le paquetage compatibilité a.out : libc.so-4.7.6. Il est marqué optionnel parce que vos bibliothèques a.out existantes continueront à marcher avec vos exécutables actuels. Vous ne le prendrez que si vous considérez de continuer à développer en a.out pour quelque raison que ce soit. BSD curses. Si vous trouvez des exécutables qui nécessitent libcurses.so.1, c'est l'ancienne version de la bibliothèque curses de BSD. Ils sont plutôt rares, ce qui est plutôt une bonne chose car je ne peux pour l'instant pas mettre la main sur une version en code source de cette bibliothèque. Il est probablement préférable de recompiler de tels programmes de manière à fonctionner avec ncurses. Vous trouverez une version compilée de libcurses.so ds libc-5.0.9.bin.tar.gz sur les sites miroirs de tsx-11. Berkeley db: les nouvelles routines BSD 4.4 libdb de base de données. Le source est téléchargeable ftp://ftp.cs.berkeley.edu/ucb/4bsd/db.1.85.tar.gz/ et le patch pour les bibliothèques partagées sous Linux est ftp://ftp.uk.linux.org/pub/Linux/libc/non-core/db.patch. C++: le paquetage gcc est fourni avec g++, mais vous aurez également besoin de libg++-2.7.1.4.bin.tar.gz pour compiler n'importe quel programme C++ utile. Pour ma part, je n'utilise pas C++ mais je suis en mesure de comprendre qu'il n'est pas aisé de compiler cela à partir du code source d'où la recommandation quant aux versions compilées. termcap compatible GNU. Le passage à ncurses ne s'est pas fait simultanément au passage à ELF - vous pourriez avoir besoin d'exécuter des programmes d'autres personnes qui font appel à cette bibliothèque. gdb en est un bon exemple. Si vous avez l'intention de déboguer des bibliothèques partagées et que gdb est troublé par celles qui sont liées à elles-mêmes, vous voudrez certainement une copie statiquement liée de celle-ci. Dans ce cas, vous trouverez qu'un véritable termcap est bien moins encombrant que des routines compatibles termcap dans ncurses. termcap-2.0.8.tar.gz se trouve sur tsx-11. Ce n'est pas le Termcap GNU, mais il lui est compatible (les différences résident apparamment dans le contrôle des erreurs). C'est un paquetage en version code source. MAKEDEV. Dans certaines implémentations, cette utilitaire efface les entrées existantes des périphériques pour les recréer par la suite. Cela peut planter certaines versions de ld-linux.so.1 s'il efface /dev/zero. Une nouvelle version est disponible à ftp://sunsite.unc.edu/pub/Linux/system/Admin/MAKEDEV-C-1.5.tar.gz ou ftp://sunsite.unc.edu/pub/Linux/system/Admin/MAKEDEV-2.2.tar.gz. modules-2.0.0. Si vous utilisez des modules, la mise à jour des binutils que vous allez bientôt effectuer va empêcher le fonctionnement de tous les utilitaires de modules plus vieux que la 1.3.69. Les nouvelles versions des modules peuvent être obtenues sur http://www.pi.se/blox/. Le système X window comporte un grand nombre de bibliothèques partagées. Comme vos nouveaux programmes seront en ELF, et que les programmes ELF ne peuvent tirer partie des bibliothèques a.out, vous allez avoir besoin d'une nouvelle installation de X si vous voulez faire un tant soit peu de développement sous X. XFree86 3.1.2 est diponible sous les formats ELF et a.out. Allez par ftp sur ftp.xfree86.org, lisez le message "too many users" que vous n'allez pas manquer de lire et choisissez le site miroir le plus proche de chez vous. Une fois que vous avez récupéré les répertoires common et elf, vous aurez alors à éditer /usr/X11R6/lib/X11/config/linux.cf pour modifier les lignes suivantes: #define LinuxElfDefault NO #define UseElfFormat NO en mettant YES à la place. Autrement, une compilation de xpm conduira à utiliser les anciens utilitaires du passé. Notez que les exécutables de Xfree86 nécessitent maintenant qu'une bibliothèque termcap partagée en ELF (libtermcap.so.2) soit installée. Si vous utilisez Motif, contactez votre fournisseur pour savoir s'il est en mesure de vous fournir des librairies partagées Motif en ELF. Ne l'utilisant pas, je ne vous suis d'aucune utilité à ce sujet. Si vous passez à Linux 2.0 en même temps que votre mise à jour à ELF, n'oubliez pas de consulter le fichier Documentation/Changes qui est fourni avec les sources du noyau pour voir de quoi vous aurez besoin par ailleurs. 2.4 Réarrangement de votre système de fichiers. Bien! Pour la suite, veuillez noter que quand j'écris "effacer", je veux dire "sauvegarder puis effacer" :-). Une bonne inspiration et on y va... primordial --- installation des exécutables Créez les nouveaux répertoires dans lesquels vous allez déplacer ce qui concerne a.out mkdir -p /usr/i486-linuxaout/bin mkdir -p /usr/i486-linuxaout/include mkdir -p /usr/i486-linuxaout/lib mkdir /lib-aout Détarrez le paquetage de l'éditeur de liens dynamique ld.so-1.7.14 dans le répertoire dans lequel vous mettez habituellement le code source et lisez de suite le script ld.so-1.7.14/instldso.sh qui vient d'être décompressé. Si vous avez réellement un système standard, lancez-le en tapant sh instldso.sh, mais si il y a quoi que ce soit d'anormal, installez-le à la main. Par anormal, je veux dire: utiliser zsh comme shell (certaines versions de zsh définissent $VERSION, ce qui semble gêner instldso.sh) avoir des liens symboliques de /lib/elf vers /lib (ce dont vous ne devriez pas avoir besoin mais c'est une bien piètre consolation quand vous êtes à la recherche de votre disquette de sauvetage) Editez /etc/ld.so.conf pour y ajouter le nouveau répertoire /usr/i486-linuxaout/lib (et /lib-aout si vous allez en avoir besoin). Relancez ensuite /sbin/ldconfig -v pour vérifier qu'il prend en compte les nouveaux répertoires. Déplacez toutes les bibliothèques a.out dans /usr/lib et /usr/*/lib vers /usr/i486-linuxaout/lib. Notez que j'ai écrit les bibliothèques et non pas tous les fichiers. Ce sont les fichiers qui correspondent à la spécification lib*.so* , lib*.sa*, ou lib*.a. Ne commencez pas à déplacer par exemple /usr/lib/gcc-lib. Regardez maintenant dans /lib. Laissez tranquille les fichiers libc.so*, libm.so*, et libdl.so*. Si vous disposez de liens symboliques vers les bibliothèques X (libX*.so.3*), laissez-les également là car Xview et d'autres paquetages en ont besoin. Laissez les fichiers ld.so*, ld-linux.so* et tous les autres fichiers commençant par ld. Pour ce qui est des autres bibliothèques (s'il en reste), si vous avez /usr sur la partition racine, mettez-les dans /usr/i486-linuxaout/lib. Si /usr est monté séparément, mettez-les dans /lib-aout. Lancez maintenant ldconfig -v. Effacez le répertoire /usr/lib/ldscripts s'il existe, en vue de l'installation des binutils (qui va le recréer) Effacez toutes les copies de ld et de as (excepté ld86 et as86) que vous trouverez dans /usr/bin. Vous devez nettoyez votre arborescence /usr/include. Sur un système normal, certains des fichiers qui se trouvent ici sont des fonctionnalités de base et sont fournis avec libc, alors que d'autres proviennent d'autres paquetages que vous ou l'auteur de votre distribution avez installé. En tenant compte de cela, je suggère que vous la reconstruisiez à partir de rien: renommez-la en /usr/include.old, et extractez libc-5.2.18.bin.tar.gz à partir du répertoire racine. Installez le paquetage binutils. tar -xvzf binutils-2.6.0.12.bin.tar.gz -C / est une bonne manière de le faire. Le paquetage gcc doit être extracté à partir de la racine. Il installe quelques fichiers dans /usr/bin et bien plus encore dans /usr/lib/gcc-lib/i486-linux/2.7.2 et /usr/lib/gcc-lib/i486-linuxaout/2.7.2. Tapez: $ tar ztf gcc-2.7.2.bin.tar.gz pour voir ce qu'il contient, sauvegardez tout ce qu'il va écraser et que vous voudriez conseerver (par exemple, si vous avez installé Gnu ADA, vous voudrez conserver /usr/bin/gcc), et tapez juste: # tar -zxf gcc-2.7.2.bin.tar.gz -C / A cette étape, vous devriez être en mesure d'exécuter gcc -v et de compiler des programmes tests. Essayez: $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2/specs gcc version 2.7.2 $ gcc -v -b i486-linuxaout Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.2/specs gcc version 2.7.2 $ ld -V ld version 2.6 (with BFD 2.6.0.2) Supported emulations: elf_i386 i386linux i386coff suivi bien sûr du programme traditionnel "Hello, world". Essayez-le avec gcc et avec gcc -b i486-linuxaout pour vérifier que les compilateurs a.out et ELF sont bien configurés. Terminé? Pas exactement. Les bibliothèques qui ne sont pas de base ne sont pas encore installées et de nombreux liens symboliques sont encore à établir. Courage... Liens symboliques Certains programmes (notamment de nombreux programmes X) utilisent /lib/cpp, qui sous Linux est généralement un lien vers /usr/lib/gcc-lib/i486-linux/version/cpp. Comme l'étape précédente a très certainement effacé la version de cpp vers laquelle il pointait, vous allez devoir recréer le lien: # cd /lib # ln -s /usr/lib/gcc-lib/i486-linux/2.7.2/cpp . Quand vous avez déplacé /usr/include vers /usr/include.old, vous avez perdu les liens symboliques à l'intérieur des sources du noyau. Faites: # cd /usr/include # ln -s ../src/linux/include/linux . # ln -s ../src/linux/include/asm . (en considérant que vos sources du noyau sont dans /usr/src/linux). Les gens de FSSTND se sont justifiés de l'avoir gardé en déplaçant les fichiers utmp et wtmp de /var/adm vers /var/run et /var/log respectivement. Vous allez devoir créer des liens en fonction de leurs emplacements et vous aurez peut-être à créer les répertoires /var/log et /var/adm. Je reproduis ci-dessous le résultat de ls -l sur mon système: $ ls -ld /var/adm /var/log /var/run /var/log/*tmp /var/run/*tmp lrwxrwxrwx 1 root root 3 May 24 05:53 /var/adm -> log/ drwxr-xr-x 9 root root 1024 Aug 13 23:17 /var/log/ lrwxrwxrwx 1 root root 11 Aug 13 23:17 /var/log/utmp -> ../run/utmp -rw-r--r-- 1 root root 451472 Aug 13 23:00 /var/log/wtmp drwxr-xr-x 2 root root 1024 Aug 13 23:17 /var/run/ -rw-r--r-- 1 root root 448 Aug 13 23:00 /var/run/utmp Consultez FSSTND (à partir des archives de la LDP telles que ftp://sunsite.unc.edu/pub/Linux/docs/fsstnd/) pour les détails. Réjouissez-vous! A cet instant, vous devriez disposer d'un environnement de développement ELF pleinement fonctionnel (enfin plus ou moins). Relaxez vous et fêtez cela pendant quelques minutes. Paquetages essentiels en code source L' installation de ncurses est un travail de longue haleine bien que vous puissiez profiter du temps de compilation pour lire l'Usenet. Après avoir décompressé le fichier tar, lisez le fichier INSTALL en vous considérant comme "un constructeur de distribution Linux ou de paquetages", à savoir que vous allez probablement le configurer avec une commande du style $ ./configure --with-normal --with-shared --disable-termcap --enable-overwrite --prefix=/usr Prenez également garde aux commentaires qui concernent le type de terminal par défaut: dans les noyaux 1.3 et 2.0, on le définit par linux au moment du boot mais vous aurez peut-être à éditer /etc/inittab pour éviter de le redéfinir en tant que console par getty. Si /usr/lib/terminfo ne se trouve pas sur le disque racine (qui contient /), vous allez avoir affaire au "support du fallback" avec ncurses. Ceci est documenté dans le fichier INSTALL mentionné ci-dessus: c'est simple mais pénible car vous allez devoir compiler la bibliothèque deux fois. Si le fait d'avoir linux et vt100 comme fallbacks ne vous dérange pas, vous pouvez copier fallback.c que vous trouverez à ftp://ftp.uk.linux.org/pub/Linux/libc/non-core/fallback.c sur l'existant. Après avoir installé ncurses, vous allez devoir bidouiller dans /usr/lib car il y fait des choses non optimales qu'il est plus simple de réparer à la main. Notez que les contradictions entre les numéros de version, bien que peu agréables, ne sont d'aucun danger pour la santé humaine. /usr/lib/libncurses.so.1.9.9e devrait être déplacé vers /lib de manière à ce que les programmes curses qui fonctionnent en mode mono-utilisateur continuent à le faire. Si /usr/lib se trouve sur votre partition racine, cela n'est pas nécessaire bien que cela ne fasse pas de mal. Dans /lib, établissez un lien vers libncurses.so.1.9.9e appelé libncurses.so.3.0. Vous aurez également besoin des liens /usr/lib/libncurses.so, /usr/lib/libcurses.so et /usr/lib/libtermcap.so qui doivent tous pointer vers /lib/libncurses.so.3.0. Pour résumer, cela donne: # cd /lib # mv /usr/lib/libncurses.so.1.9.9e . # ln -s libncurses.so.1.9.9e libncurses.so.3.0 # cd /usr/lib # ln -s /lib/libncurses.so.3.0 libncurses.so # ln -s /lib/libncurses.so.3.0 libcurses.so # ln -s /lib/libncurses.so.3.0 libtermcap.so Installation de gdbm. Décompressez le code source dans un répertoire de code source, appliquez le patch gdbm.patch, et consultez les fichiers README et INSTALL. La procédure de compilation sera alors du genre: $ tar zxf gdbm-1.7.3.tar.gz $ patch -p0 < gdbm.patch $ cd gdbm-1.7.3 $ ./configure --prefix=/usr $ make $ make progs $ su # make install # make install-compat # cd /usr/lib # ln -s libgdbm.so.1 libgdbm.so # ln -s libgdbm.so.1 libgdbm.so.2 # ldconfig La dernière étape est pour la compatibilité ascendante: certaines distributions utilisent libgdbm.so.2 qui contient le même code que libgdbm.so.1 mais mal numéroté pour des raisons historiques. Paquetages optionnels en code source. En général, vous pouvez vous contenter de les installer en suivant les procédures qu'ils indiquent que je ne vais donc pas répéter. Il y a toutefois deux exceptions: Si vous voulez termcap version GNU (optionnel à strictement parler mais nécessaire pour utiliser les exécutables XFree86), il doit être compilé à partir du code source mais cela ne devrait pas être plus compliqué que $ tar zxf termcap-2.0.8.tar.gz $ cd termcap-2.0.8 $ make $ su # cp libtermcap.so.2.0.8 /usr/lib # ldconfig Je vous recommande de ne pas faire make install pour ne pas compromettre l'installation antérieure de ncurses. Si vous avez besoin de compiler des choses à partir de cette bibliothèque plutôt que simplement exécuter des exécutables faits avec elle, pensez à placer en lieu sûr les fichiers d'en-tête et les bibliothèques statiques et à utiliser les commutateurs -I et -L quand vous compilerez les choses en question. L'aspect vague de cette description devrait rendre clair que l'utilisation de termcap est déconseillée à moins que vous n'ayez de bonnes raisons. Pour libdb, c'est quelque chose du genre: $ tar zxf db.1.85.tar.gz $ patch -p0 <db.patch $ cd db.1.85/PORT/linux $ make $ su # mkdir /usr/include/db # ldconfig # cp libdb.so.1.85.3 /usr/lib ; ( cd /usr/lib && ln -s libdb.so.1 libdb.so ) # cp ../../include/*.h /usr/include/db Veuillez noter vous n'appliquez pas PORT/linux/OTHER_PATCHES car il est contenu dans ce patch vous installez les fichiers d'en-tête autre part que dans /usr/include --- il y a en effet conflit avec ceux que gdbm utilise. Pour compiler les programmes qui nécessitent libdb, vous devrez ajouter -I/usr/include/db à la ligne de commande du compilateur C. 2.5 A quoi cela devrait ressembler (les grandes lignes de l'arborescence des répertoires) Ceci est un guide délibérément vague qui indique en gros ce que sont les fichiers que vous venez d'installer. Cela peut être utile dans un contexte de dépannage ou si vous décidez d'effacer quelque chose. /lib L'editeur dynamique de liensld.so (a.out) et ld-linux.so.1 (ELF). Chacun d'entre eux peut être un lien symbolique mais vérifiez que les fichiers vers lesquels ils pointent existent. Les bibliothèques partagées de base libc.so.4 et libm.so.4 (a.out). Ce sont des liens symboliques dont il faut vérifier qu'ils pointent vers des fichiers réels. Les bibliothèques partagées de base libc.so.5, libm.so.5, libdl.so.1,libncurses.so.1,libtermcap.so.2, (ELF). Encore des liens symboliques, même remarque que ci-dessus /usr/lib Tous les fichiers qui ne sont pas des bibliothèques et les répertoires qui étaient là auparavant. libbfd.so*,libdb.so*, libgdbm.so*: bibliothèques partagées ELF. Encore des liens symboliques. Pour chacune des bibliothèques dans /lib ou /usr/lib, il devrait y avoir un lien symbolique ici. Le nom du lien devrait être le véritable nom du fichier en enlevant le numéro de version. Par exemple libc, lrwxrwxrwx 1 root root 14 May 2 20:09 /lib/libc.so.5 -> libc.so.5.3.12 -rwxr-xr-x 1 bin bin 583795 Apr 25 06:15 /lib/libc.so.5.3.12 lrwxrwxrwx 1 root root 12 Oct 27 1995 /usr/lib/libc.so -> /lib/libc.so.5 Ces liens sont utilisés par ld au moment de l'édition des liens. libbsd.a, libgmon.a, libmcheck.a, libmcheck.a et un fichier lib*.a pour chacune des bibliothèques partagées ELF dans /lib et /usr/lib. Les bibliothèques ELF statiques. Celles qui sont l'équivalent des librairies partagées ne seront pas d'une grande utilité pour la plupart des gens --- quand vous utilisez ELF, vous pouvez employer le commutateur gcc -g avec les bibliothèques partagées, il n'y a donc plus de raison d'utiliser les versions statiques. Vous en aurez besoin si vous voulez déboguer les bibliothèques elles-mêmes. crt0.o, gcrt0.o. fichiers de "début de programme" en a.out; l'un d'entre eux est lié en tant que premier fichier dans tout programme a.out que vous compilez, à moins que vous ne vous arrangiez pour qu'il n'en soit pas ainsi. crt1.o, crtbegin.o, crtbeginS.o, crtend.o, crtendS.o, crti.o, crtn.o, gcrt1.o. Fichiers de démarrage ELF. Ils font la même chose que les fichiers *crt0.o ci-dessus pour les programmes ELF. /usr/lib/ldscripts C'est là que les scripts de gestionnaires de périphériques pour ld vont, comme le nom le suggère. Cela devrait ressembler à: $ ls /usr/lib/ldscripts/ elf_i386.x elf_i386.xs i386coff.xn i386linux.xbn elf_i386.xbn elf_i386.xu i386coff.xr i386linux.xn elf_i386.xn i386coff.x i386coff.xu i386linux.xr elf_i386.xr i386coff.xbn i386linux.x i386linux.xu /usr/i486-linux/bin ar, as, gasp, ld, nm, ranlib, strip. Ce sont des liens symboliques vers les binutils réels de /usr/bin. /usr/i486-linuxaout/bin as --- l'assembleur a.out, and gasp, son préprocesseur de macro ar, ld, nm, ranlib, strip --- liens symboliques vers les binutils réels de /usr/bin /usr/i486-linux/lib ldscripts est un lien symbolique vers /usr/lib/ldscripts. /usr/i486-linuxaout/lib lib*.so*. Images de la bibliothèque partagée a.out. Nécessaire pour exécuter des programmes a.out. lib*.sa. Bases de la bibliothèque partagée a.out. Nécessaires pour compiler les programmes a.out qui utilisent des bibliothèques partagées. Si vous n'en avez pas l'intention, vous pouvez sans problème les effacer. lib*.a. Bibliothèques statiques a.out. Nécessaires pour compiler les programmes statiques a.out (à savoir quand vous compilez avec -g). Vous pouvez aussi les effacer si vous n'avez pas l'intention de compiler de tels programmes. ldscripts est un lien symbolique vers /usr/lib/ldscripts /usr/lib/gcc-lib/i486-linux/2.7.2 Ce répertoire contient une version de gcc 2.7.2 configurée pour compiler les programmes ELF. /usr/lib/gcc-lib/i486-linuxaout/2.7.2 Ce répertoire contient une version de gcc 2.7.2 configurée pour compiler les programmes a.out qui tient compte de la nouvelle arborescence de répertoires. Si vous n'avez pas l'intention de compiler quoi que ce soit en a.out, l'effacer devrait libérer environ 4Mo. Notez que vous devez les conserver si vous voulez compiler des noyaux 1.2 non-patchés. 2.6 Erreurs communes --- Ne paniquez pas! Vous avez déplacé la mauvaise chose et maintenant plus rien ne fonctionne Votre shell tourne toujours et en vous donnant un peu de mal, vous pouvez faire beaucoup avec les commandes intégrées du shell. Souvenez vous que echo * remplace très bien ls, et que echo >>filename peut être utilisé pour ajouter des lignes à un fichier. N'oubliez pas non plus que ldconfig est lié statiquement. Si vous avez déplacé, par exemple, libc.so.4 vers /lib-aout par erreur, vous pouvez faire echo "lib-aout" >>/etc/ld.so.conf ; ldconfig -v/ et vous retrouver sur vos pieds. Si vous avez déplacé /lib/ld.so, vous pourrez sûrement faire sln /silly/place/ld.so /lib/ld.so, si ln est lié statiquement, et une fois de plus vous retrouver sur vos pieds. bad address quand vous essayez d'exécuter quoi que ce soit d'ELF. Vous utilisez un noyau 1.3.x, où x<3. Arrêtez tout de suite. Ce sont probablement les noyaux les plus bogués de la planète. Passez au 2.0 ou revenez au 1.2.13. Certaines personnes font également état de "kernel panics" dans des circonstances similaires; je ne me suis pas penché sur la question principalement parce que je ne vois pas de raisons d'utiliser les noyaux de développement sans suivre les mises à jour. gcc: installation problem, cannot exec quelque chose: No such file or directory quand vous essayez de faire des compilations a.out (quelque chose est généralement cpp ou cc1). Ou bien cela est vrai ou bien vous avez tapé $ gcc -b -i486-linuxaout quand vous auriez du taper $ gcc -b i486-linuxaout Le "i486" ne commence pas par un tiret. make: *** No targets specified and no makefile found. Stop. indique que vous n'avez pas patché ou recompilé make, ou que vous en avez toujours une vieille version quelque part sur le système. no such file or directory: /usr/bin/gcc (ou n'importe quel autre fichier que vous essayez d'exécuter) quand vous savez qu'un tel fichier existe. Cela veut généralement dire que le chargeur dynamique ELF /lib/ld-linux.so.1 n'est pas installé ou est illisible pour une raison ou pour une autre. Vous auriez du l'installer antérieurement, aux alentours de l'étape 2. not a ZMAGIC file, skipping selon ldconfig. Vous avez une vieille version du paquetage ld.so, donc récupérez-en une plus récente. Voir étape 2 de l'installation. _setutent: Can't open utmp file Ce message apparaît souvent en groupe de trois quand vous lancez un xterm. Veuillez consulter la tirade sur FSSTND vers la fin des instructions d'installation. Page suivante Page précédente Table des matières