Installing Bash as the very first package allows us to specify the "configure shell" to be used by all Autoconf-produced configure scripts during the Temptools phase. This is achieved via the CONFIG_SHELL environment variable mentioned earlier. It serves to enhance the robustness of the build method by reducing reliance on the host's /bin/sh thus avoiding potential breakage when bootstrapping from older distros.

Another reason for installing Bash first up is that we can write our build script using all the features of modern Bash without having to worry about which shell is installed as /bin/sh on the host. Simply launch your build script like this: `bash-pass1 myscript.sh'.

Tip

There is additional benefit to using this technique in that it allows greater flexibility for handling the transition between the Temptools and Chroot phases. For example, you can set the interpreter path in your build script to `#!/temptools/bin/bash' which allows easy re-execution of the same script upon entering the chroot environment without having to fuss over having a `$SYSROOT/bin/sh' symlink already set up. Please refer to the author's own gsbuild scripts for a sample implementation. Naturally, this point is moot if you script in pure Bourne or handle the Temptools/Chroot phases transition using a different method.

For our purposes of bootstrapping a new Linux system within the Reference Build context, Bash should build fine on any sane distro made within the last 5 years.

The "unset CONFIG_SHELL" in the configure invocation is needed for configure to succeed because the shell pointed to by CONFIG_SHELL doesn't exist yet i.e. we are installing it here.

Note: some older hosts have `libtermcap' installed and Bash will prefer it over Ncurses if found by configure unless `--with-curses' is given. Bash also comes with its own Termcap. Rather than tinker with configure switches, it's actually more robust to just let configure work it out for itself. This Pass 1 of Bash is simply for running scripts during the Temptools phase so it shouldn't really matter which Termcap is used.

Double ampersands are used here because we're still operating in an interactive shell session at this point. We recommend that you employ a proper error trapping strategy in your build script (eg: set -e). Therefore, double ampersands are not provided in the build commands from this point onwards.

for bootstrapping purposes, Make should build fine on any sane distro made from 1999 onwards.

the Glibc build needs a version of `make' 3.79 or newer which older distros don't have. We remove all doubts by installing the current version. Why install it now rather than just prior to the Glibc build? Well, it makes sense to integrate it from the outset so that we can start using it immediately.

the `gmake' symlink is needed for robustness. `gmake' already exists on some hosts which will prevent Glibc's configure script from finding the `make' we install here.

for bootstrapping purposes, Sed should build fine on any sane distro made from 1999 onwards.

The ac_cv_header_stdbool_h=yes tweak is needed when building on older hosts. Please read this bug report for details. Note that on newer hosts the variable is set automatically by configure thus making the tweak unnecessary, but it's perfectly fine to leave it there in all circumstances.

Why do we install a Pass 1 of Sed here? There have been reported problems where the Glibc build chokes with older Sed versions. The author hasn't personally seen any such problem but feels it's safer to just install a current Sed from the outset. An added bonus is that we can rely on using `sed -i' during the entire Temptools phase thus simplifying scripting.

The `echo "MAKEINFO = :" >> Makefile' tweak is used to remove dependence on `makeinfo' and therefore eliminate all associated problems. Please read the mailing list thread starting with this post for details.

We create a lib64 -> lib symlink in the x86_64 case because we are not building a multi-arch toolchain. Even in single-arch mode 64-bit architectures tend to hardwire references to "lib64" in many places throughout the toolchain. It's possible to force everything to "lib" but we'd rather keep all the build commands compatible with other architectures. The symlink keeps things sane and everything Just Works™.

After the first Binutils are installed, -B/usr/bin/ is temporarily added to the CC definition in order to force the host GCC to use the host Binutils. Without this override, the host GCC will find the newly installed Binutils in the PATH thus causing a toolchain mismatch and potential breakage. This breakage is likely to strike when using a bleeding edge distro as a host (eg: Fedora) and you're building a toolchain comprised of older versions of toolchain components than those on the host. The "if..echo..grep" statement is required on those hosts with GCC-2.95.x or earlier installed. More background on all of this can be found in the mailing list thread starting with this post (continued here).

Note: Unlike LFS, we don't statically link the Pass 1 of Binutils because it's simply unnecessary, and in actual fact is a potential source of failure. We therefore link dynamically for robustness reasons. If you still think static linking is a good idea then at least take note of the Glibc maintainer's views on the subject.

Because we're linking dynamically, there's no need to specify `make configure-host' after the initial configure. However, when building on SMP the top level Makefile will run the sub-configure scripts for Libiberty and Binutils simultaneously. This is great for speed and efficiency, but unfortunate for the build log which ends up all jumbled. If you'd like the build log to remain neat and tidy (eg: for diffing purposes), run the sub-configure scripts in serial by executing make configure-host -j1 after the initial configure.

GCC-4.3 and above requires the MPFR and GMP libraries. Here we are taking advantage of the largely undocumented "combined tree" feature of the GNU toolchain. Integrating MPFR and GMP into the GCC build itself greatly simplifies matters and mostly removes all host issues and other complications of building these libs separately. More information in this mailing list post.

The switches `--disable-libmudflap', `--disable-libssp', `--disable-libgomp' and `--disable-decimal-float' first appeared in GCC-4.0, GCC-4.1, GCC-4.2 and GCC-4.3 respectively. They are used here to streamline our initial "bootstrap" GCC. The switches are all compatible within supported GCC versions ie: earlier versions simply ignore the later switches.

Note: Starting with GCC-4.2, the top-level bootstrap mechanism became the default. This means a plain "make" will now default to performing a 3 stage bootstrap unless `--disable-bootstrap' is given. The pre-GCC-4.2 method of "make bootstrap" behaves identically. Therefore, we can maintain compatibility with earlier versions by continuing to use "make bootstrap".

The libgcc_eh.a symlink is needed to satisfy the upcoming Glibc build. Please read this mailing list post for some rationale discussion.

Note: There is no need to specify `ARCH=xxx' above because as of kernel 2.6.24, the x86 headers produced for 32-bit and 64-bit arches are identical. More information in this mailing list post.

We need to fiddle with `-march=' in CFLAGS because as of Glibc-2.6, i486 is the minimum supported configuration on x86. More information here.

`--without-selinux' is a workaround needed on Fedora Core 3 hosts (those with the "libselinux-devel" package installed) to prevent build failure caused by a subtle Makefile bug. Upstream have been notified of the issue.

`AUTOCONF=no' is used here for robustness. It simply prevents unnecessary Autoconf invocations when the Makefiles detect a `configure' file older than its respective `configure.in'. This is usually the case when working with CVS snapshots, but it also applies to release tarballs prior to glibc-2.3.5 when the issue was finally addressed. These unnecessary Autoconf invocations have been known to cause build failures on Debian hosts. An alternative approach is to run `find . -name configure | xargs touch' in the src dir before running `configure'. Note: `--without-cvs' does not address the issue.

`MAKEINFO=:' is used to prevent installation failures when the host has an older `makeinfo'. Problems were first noticed with Glibc-2.7.

For x86_64 we need to empty the "multilib" spec to prevent GCC from searching for libs on the host. The sed simply modifies the spec to mirror how it would appear in a single-arch scenario. More information in this mailing list post.

The tweak to STANDARD_STARTFILE_PREFIX_{1,2} ensures there is zero chance of any libs and startfiles being found on the host. More information in this mailing list post. Some older information related to the same issue can be found here.

As mentioned earlier, we need to pass `--disable-bootstrap' here to prevent GCC-4.2 and above from performing a 3 stage bootstrap. The switch is ignored by earlier versions and is therefore compatible.

The notes about `make configure-host' from Binutils Pass 1 and GCC Pass 1 also apply here. However, it gets a little more complicated because we're also building Libstdc++. To achieve the same outcome (ie: run sub-configures in serial for neat build logs under SMP), the sequence needs to be like this:

make configure-host -j1
make all-host
make configure-target -j1
make all-target

When building with GCC-4.x we use a sed to add `-fomit-frame-pointer' to the GCC Makefile to address a correctness issue. Please read this mailing list post for some rationale discussion.

Please skip ahead to Section 4.23, “Gawk-3.1.6” for some rationale discussion about the `ac_cv_func_working_mktime=yes' tweak.

For some background on the `--enable-install-program=hostname,su' configure switch, please read this mailing list post.

Because we are operating as a non-privileged user, Coreutils will suppress installation of the `su' program. This is signified by a message shown during `make install': "WARNING: insufficient access; not installing su NOTE: to install su, run 'make install-root' as root". The reason for this is `su' needs to be installed setuid root in order to be fully functional. We manually install it here because even without the setuid bit, we can still use it when inside the Chroot environment to (a) run various testsuites as a non-privileged user and (b) employ Package Management techniques that require building sources as a non-privileged user.

The `MISSING=true' tweak is needed to work around a bug in the current release whereby the build will fail if `makeinfo' is unavailable. See here and here for examples.

Please skip ahead to Section 4.45, “Bash-3.2” for some rationale discussion about the `--without-bash-malloc' switch.

Please skip ahead to Section 4.23, “Gawk-3.1.6” for some rationale discussion about the `ac_cv_func_working_mktime=yes' tweak.

We install the E2fsprogs libraries here to satisfy the build of `mount' from Util-Linux-ng in the next step. If you choose not to build `mount' then these libraries are naturally not required.

We install `mount' here so we can mount the virtual file systems from within the chroot environment. Please read this mailing list post for some rationale discussion.

We install `getopt' here because it's needed by the optional Fakeroot package (see below). If you're not installing Fakeroot then you don't need to install `getopt' here.

For some background on the commands containing "static_ext" and "ext/Errno/pm_to_blib" please read the mailing list thread starting with this post.

The sed to `configure' forces Expect to call a plain `stty' instead of `/bin/stty' or even worse, `/usr/local/bin/stty'. In this way the first `stty' in the PATH will always be used. It also avoids the need to create a `/bin/stty' symlink in Section 4.5, “Create Symlinks”.

As mentioned in the Introduction, if you're employing Package Management by building and creating archives as a non-privileged user, files in the resultant archives can sometimes end up with wrong file ownerships and permissions. Fakeroot can provide a solution to this problem. It acts as a wrapper around various library functions and a typical invocation is like this: fakeroot commands-you-want-run-under-a-fake-root-environment. Generally, you only want to be performing the commands associated with installation under Fakeroot. Running commands associated with configuring and building usually work, but the Fakeroot documentation recommends against it. Never run the testsuites for Glibc, Coreutils and Perl under Fakeroot because you will experience failures. The Bash testsuite can also be problematic. Consider this package optional if you're a) not employing Package Management b) building as root or c) using a Package Manager that doesn't require assistance from Fakeroot.

The sed is needed to force Fakeroot to load the correct Glibc when inside the Chroot environment. Without it, Fakeroot will load the Temptools Glibc.

Another package with similar functionality but having a slightly different feature set is Pretendroot. Details on this package can be found here. Note: we haven't tested Pretendroot in the context of a Reference Build so your mileage may vary.