Stability and debugging

Declan Moriarty junk_mail at
Sat Jul 22 12:56:31 PDT 2006

On Sat, 2006-07-22 at 00:44 -0400, Robert Connolly wrote:
> On July 21, 2006 06:12 am, Sebastian Faulborn wrote:
> > >>I would also like to install Valgrind in /tools...
> > >>Valgrind, and Lint/Splint, can also be used later to test the rest of our
> > >>packages...
> >
> > I think this would be an excellent idea. However the work to maintain
> > 2 seperate books is error-prone.
> I didn't mean two books. Maybe something like "Debugging notes" in the book 
> with commands which are not in a <screen> window, so you would have to go out 
> of your way to copy/paste it. With something like GCC, I don't expect many 
> people will be willing to perform a 200+ SBU debugging test... probably less 
> than 1% of users would be willing. But with the handfull of suid programs in 
> the base running Valgrind on them would probably take less than half an SBU, 
> so these could be in a <screen> window for everyone to run.
> By the way, the 200+ SBU is for all the checks... assert, fold, gc, gcac, 
> misc, rtl, rtlflag, runtime, tree, valgrind, not valgrind alone.

These sort of results question the whole business of compiling from
scratch. I have gathered this much

1. Compiling new versions (particularly gcc-4.1x) the way LFS does it is
somewhere between a major PITA and impossible.

2. I sense a lessening confidence in the quality of the toolchain among
the guys who should know here and that frankly undermines the whole

3. The predictability of results on the range lfs ideally wants to cover
ix86 32bit & 64 bit, amd & intel, and ideally ppc, sparc, etc. is
lessening with advances in complexity. Introducing valgrind will add
noticeably to times. 200 SBUs is enough to frighten anyone off.

Others with deeper knowhow could no doubt add to this.

Given the above, is there not a strong argument for this approach:
Alter the content of a release. Make it a book and the appropiate
tarball containing a prebuilt toolchain.

The process would then be one of either
	1. Build your own toolchain with slightly different options if you were
going somewhere odd with your particular system or
	2. Use the tarball as the final toolchain, and build the system
Valgrind could then be compiled once, and then distributed.  There would
be no need for a static build, the educational function of which is near
zero anyhow. Anyone who deviates one iota from the book in chapter 5 is
screwed, so the whole idea of compiling 'for choice of options' is gone.
It should be possible to install this way without any preexisting linux
on the box with a few tweaks. Or mebbe the live cd would allow you to
skip chapter 5 anyhow.
        With Best Regards,

        Declan Moriarty.

More information about the hlfs-dev mailing list