Top level make/bootstrap

Robert Connolly robert at linuxfromscratch.org
Tue Jul 11 15:43:22 PDT 2006


Hi. I read:
http://gcc.gnu.org/install/
http://gcc.gnu.org/wiki/Top-Level Bootstrap

and I've been experimenting with it. I really like this build system. This 
build system is extremely similar to what the BSD's use. Its a combined 
source tree, which can also be read-only. The GCC package holds the master 
makefiles, and currently supports the following packages:

texinfo byacc flex bison binutils gas ld fixincludes gcc sid sim gdb make 
patch prms send-pr gprof etc expect dejagnu ash bash bzip2 m4 autoconf 
automake libtool diff rcs fileutils shellutils time textutils wdiff find 
uudecode hello tar gzip indent recode release sed utils guile perl gawk 
findutils gettext zip fastjar gnattools

and it is not difficult to add or modify this to add others, like coreutils.

Some of our patches engage the packages to rebuild info doc files, to the 
source directory. Some of our info files need to be touched, to reset the 
timestamp, in order to keep the sources read-only.

The following is a demonstration of this build system:

---

Make a couple directories (as root):

install -v -d -o root $LFS/usr/
install -v -d -o lfs $LFS/usr/src/packages/

Put your tarballs in $LFS/usr/src/packages/.

GCC's Makefile.def uses the wrong RPATH_ENVVAR for bfd and opcodes. To edit 
the Makefile.def and apply changes to Makefile.in we need to install the 
autogen package to /tools. Do that first (as user lfs):

cd $LFS/usr/src/ &&
tar jxvf autogen-5.8.4.tar.bz2 &&
cd autogen-5.8.4/ &&
./configure --prefix=/tools --without-libxml2 --without-libregex &&
make && make install

Install Binutils source:

cd $LFS/usr/src/ &&
tar -jxvf packages/binutils-2.17.tar.bz2 &&
mv -v binutils-2.17/* . &&
rmdir -v binutils-2.17/

Install GCC Core source. GCC has to be unpacked last because it will overwrite 
some of Binutils' files:

cd $LFS/usr/src/ &&
tar -jxvf packages/gcc-core-4.1.1.tar.bz2 &&
mv -v gcc-4.1.1/* . &&
rmdir -v gcc-4.1.1/

Fix the RPATH_ENVVAR bug with bfd and opcodes, so --enable-shared will work:

cd $LFS/usr/src/ &&
cp -v Makefile.def Makefile.def.orig &&
sed 's at lib_path=.;@lib_path=.libs;@' Makefile.def.orig > Makefile.def &&
rm -vf Makefile.def.orig &&
autogen Makefile.def

Make the sources read-only, and create the object directory:

cd $LFS/usr/src/ &&
install -v -d objdir/ &&
chmod -v -R -w . &&
chmod -v +w objdir

Build and install GCC and Binutils:

cd $LFS/usr/src/objdir/ &&
../configure --prefix=/tools --disable-nls \
        --disable-libmudflap --disable-libssp \
        --enable-languages=c --enable-shared \
        --enable-checking --enable-werror \
        --with-cpu=$(uname -m) --with-arch=i386 &&
make &&
make install

---

And that's how to build and install the Pass 1 tools with a top level 
makefile. This compile takes me 12 minutes, which is a pretty normal time for 
Binutils+GCC-Core. --enable-bootstrap can be added, to perform a 3 stage 
bootstrap of all the tools and their libraries, which takes me about 54 
minutes. My SBU time is 3 minutes.

--enable-bootstrap can be used in all 3 toolchain builds, but it probably best 
to only do it once.

Every package in /tools can be added to this tree and installed in order of 
dependency, and repeated in chapter 6. Pretty much any package that uses 
autoconf can be added, except Glibc which is currently not supporting this (I 
think).

The objdir can be a symlink, allowing the unpacked source to reside on a 
cdrom, or some other read-only place.

Because the system will build every tool it finds the pass 1 tools will need 
to be symlinked to a private directory just for Binutils and GCC. Something 
like symlinking /usr/src/packages/binutils-2.17/* to /usr/src/pass1... but I 
haven't got this far yet. We also need to make sure our patches do not hard 
code paths, the way the lfs-gcc-specs, and perl-libc, patches do. The 
hlfs-gcc-specs_x86 patch fixes this problem with gcc.

I realize this build system takes away some of the 'from scratch', but it is 
still from scratch. This system does not depend on or use anything not 
already in LFS/HLFS (the autogen program can be eliminated). It takes greater 
advantage of our package's features, and that's usually good thing.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20060711/8b925271/attachment.sig>


More information about the hlfs-dev mailing list