Certains programmes utilisent des chemins liés en dur à des programmes qui n'existent pas encore. Afin de satisfaire ces programmes, créez un certain nombre de liens symboliques qui seront remplacés par des fichiers réels tout au long du chapitre suivant après que le logiciel a été installé
ln -sv /tools/bin/{bash,cat,echo,grep,pwd,stty} /bin
ln -sv /tools/bin/file /usr/bin
ln -sv /tools/lib/libgcc_s.so{,.1} /usr/lib
ln -sv /tools/lib/libstdc++.so{.6,} /usr/lib
sed -e 's/tools/usr/' /tools/lib/libstdc++.la > /usr/lib/libstdc++.la
ln -sv bash /bin/sh
Voici l'objectif de chaque lien :
/bin/bash
Plusieurs scripts bash spécifient /bin/bash.
/bin/catCe chemin est codé en dur dans le script de configuration de Glibc.
/bin/echo
Ceci satisfait l'un des tests de Glibc, qui s'attend à trouver
/bin/echo.
/bin/grep
Cela évite une référence à /tools
codée en dur dans Libtool.
/bin/pwdCertains scripts configure, en particulier dans Glibc, ont ce chemin codé en dur.
/bin/sttyCe chemin est codé en dur dans Expect, donc il est requis pour que les suites de tests de Binutils et GCC réussissent.
/usr/bin/fileLes scripts configure de Binutils spécifient cette emplacement de la commande.
/usr/lib/libgcc_s.so{,.1}Glibc requière cela pour que la bibliothèque pthreads fonctionne.
/usr/lib/libstdc++{,.6}Cela est requis par plusieurs tests dans la suite de tests de Glibc, ainsi que pour le support de C++ dans GMP.
/usr/lib/libstdc++.la
Cela évite une référence à /tools
qui se trouverait dans /usr/lib/libstdc++.la après l'installation de
GCC.
/bin/sh
Plusieurs scripts shell codent en dur /bin/sh.
/sbin/initCela est où le noyau s'attend à trouver init.
Historiquement, Linux maintient une liste des systèmes de fichiers
montés dans le fichier /etc/mtab. Les
noyaux modernes maintiennent cette liste en interne et l'exposent aux
utilisateurs via le système de fichier /proc. Pour satisfaire les utilitaires qui
s'attendent à trouver /etc/mtab, créez
le lien symbolique suivant :
ln -sv /proc/self/mounts /etc/mtab