Some programs use hard-wired paths to files which do not exist yet. In order to satisfy these programs, create a number of symbolic links which will be replaced by real files throughout the course of the next chapter after the software has been installed.
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
The purpose of each link:
/bin/bash
Many bash scripts
specify /bin/bash
.
/bin/cat
This pathname is hard-coded into Glibc's configure script.
/bin/echo
This is to satisfy one of the tests in Glibc's test suite,
which expects /bin/echo
.
/bin/grep
This to avoid a hard-coded /tools
reference in Libtool.
/bin/pwd
Some configure scripts, particularly Glibc's, have this pathname hard-coded.
/bin/stty
This pathname is hard-coded into Expect, therefore it is needed for Binutils and GCC test suites to pass.
/usr/bin/file
Binutils' configure scripts specify this command location.
/usr/lib/libgcc_s.so{,.1}
Glibc needs this for the pthreads library to work.
/usr/lib/libstdc++{,.6}
This is needed by several tests in Glibc's test suite, as well as for C++ support in GMP.
/usr/lib/libstdc++.la
This prevents a /tools
reference
that would otherwise be in /usr/lib/libstdc++.la
after GCC is installed.
/bin/sh
Many shell scripts hard-code /bin/sh
.
/sbin/init
This is where the kernel expects to find init.
Historically, Linux maintains a list of the mounted file systems in
the file /etc/mtab
. Modern kernels
maintain this list internally and expose it to the user via the
/proc
filesystem. To satisfy utilities
that expect the presence of /etc/mtab
,
create the following symbolic link:
ln -sv /proc/self/mounts /etc/mtab