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 :
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.
/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.
mv, ln ou d'autres commandes de manipulation de fichier pourraient vous aider à sortir des situations périlleuses dans lesquelles vous pourriez vous mettre.
/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!
/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û.
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.
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).
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.
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.
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.
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
.
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.
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.
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/
.
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
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.
Documentation/Changes qui est fourni avec les sources du noyau pour voir de quoi vous aurez besoin par ailleurs.
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
mkdir -p /usr/i486-linuxaout/bin
mkdir -p /usr/i486-linuxaout/include
mkdir -p /usr/i486-linuxaout/lib
mkdir /lib-aout
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:
$VERSION, ce qui semble gêner instldso.sh)
/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)
/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.
/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.
/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.
/usr/lib/ldscripts s'il existe, en vue de l'installation des binutils (qui va le recréer)
ld et de as
(excepté ld86 et as86) que vous trouverez dans /usr/bin.
/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.
tar -xvzf
binutils-2.6.0.12.bin.tar.gz -C / est une bonne manière de le faire.
/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
/usr/bin/gcc), et tapez juste:
# tar -zxf gcc-2.7.2.bin.tar.gz -C /
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
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
/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 .
/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 .
/usr/src/linux).
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
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
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
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.
/lib, établissez un lien vers libncurses.so.1.9.9e appelé libncurses.so.3.0.
/usr/lib/libncurses.so,
/usr/lib/libcurses.so et /usr/lib/libtermcap.so qui doivent tous pointer vers /lib/libncurses.so.3.0.
# 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
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
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:
$ tar zxf termcap-2.0.8.tar.gz
$ cd termcap-2.0.8
$ make
$ su
# cp libtermcap.so.2.0.8 /usr/lib
# ldconfig
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.
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
PORT/linux/OTHER_PATCHES car il est contenu dans ce patch
/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.
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
ld.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.
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.
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
libbfd.so*,libdb.so*, libgdbm.so*: bibliothèques partagées ELF.
/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
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
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
/usr/lib/gcc-lib/i486-linuxaout/2.7.2
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
$ gcc -b i486-linuxaout
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.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre