g.esp at free.fr
g.esp at free.fr
Wed May 9 14:27:33 PDT 2012
----- Mail original -----
> De: "Jeremy Huntwork" <jhuntwork at lightcubesolutions.com>
> À: "LFS Developers Mailinglist" <lfs-dev at linuxfromscratch.org>
> Envoyé: Mercredi 9 Mai 2012 22:19:27
> Objet: [lfs-dev] Suggestion
> Greetings all,
> Consider two things:
> 1. We all hate long build times. Anything we can (reasonably and
> accurately do) to speed up the build we do.
> 2. Chapter 5 are a set of throwaway tools (in some cases we only build
> just what we want out of those tools, again, for sake of speed, i.e., gettext)
> Given the above, why don't we use busybox in chapter 5? If we
> standardize a config we could get rid of 12 packages in chapter 5,
> namely: ncurses, bash, bzip2, coreutils, diffutils, findutils, gawk,
> grep, gzip, sed, tar, xz. Possibly 13, patch, although the last time I
> tested busybox's patch it didn't quite work as hoped, but it's
> possible it is fixed now.
> In addition to being able to drop those packages, you also get free of
> charge a vi editor and wget utility for use in chroot.
> Thoughts? If interested, I could start a mockup in the jh branch.
I like busybox but I am not sure that busybox tools will always produce the same result as their fat counterpart.
It is likely you may encounter some issues when compiling new packages. bb sed sometime fail like recently
Anyway busybox code is well maintained and more testing should made busybox better.
Since some years ipcop build system package the toolchain in a tar.bz2, so I could choose to build chap6 fast or chap5+chap6.
The only drawback from this packaged toolchain is that if I patch glibc, I need the exact same glibc from chap5 and chap6.
The reason is that tcl/expect/dejagnu are only build in chap5 and I am testing some BLFS packages with chap5 tcl. With a different glibc, segfault may happen. Maybe that's not so wise to test BLFS with chap5 tools, I have many tcl warnings with krb-1.9.3 but I haven't yet found the time to test if rebuilding tcl/expect/dejagnu after chap6 solve those warnings.
With a packaged toolchain and ccache, build is much faster for sure. ccache divide by 3 a kernel rebuild time.
More information about the lfs-dev