Build is verified!

Ian Molton spyro at f2s.com
Thu Mar 20 03:17:16 PST 2003


On Thu, 20 Mar 2003 05:19:29 +0000 (UTC)
gschafer at zip.com.au (Greg Schafer) wrote:

> On Thu, Mar 20, 2003 at 04:25:45AM +0000, Ian Molton wrote:
> > Thanks a lot. Thats the last time I stick up for you round here.
> > I've defended the 'pure LFS' stuff before now, not, evidently, that
> > you care.
> 
> All I care about is building a clean system and the reputation of the
> LFS project.

I noticed that politeness did appear to have gone missing from that list
:/

> > would you like to actually explain (as asked) how a broken host
> > compiler can actually be garaunteed to produce a working compiler
> > from which to bootstrap other things?
> 
> It cannot. As long as a broken host cc can build the gcc-stage1 xgcc
> and the subsequent stages pass the object file comparison tests, then
> all is sweet. Looked at the gcc Makefile lately? Look for the
> "compare" targets.

Yes, I know GCC does a 3 stage 'bootstrap', in that it builds an
unoptimised stage1, and then subsequently  an optimised stage 2 and 3
using stage 1 and 2 respectively.

if the host compiler b0rks stage1, there IS a chance that it can compile
an identical (but still b0rken) stage 2 and 3. you CANNOT deny this.
This is the sort of thing that /might/ happen - I say SORT OF thing,
because this specific example would probably not, but it should give the
idea...

host compiler compiles b0rken stage1, which should contain this code:

int squiggle(int b, c){
	int d;
	d = foo(b + c);
	return d
}

now, it might just so happen that in the process of compiling stage 2,
that c is ONLY ever set to 0, but the borken stage1 has a bug that
compiles the code as:

int squiggle(int b, c){
	int d;
	d = foo(b);
	return d
}

Which, since c is only ever set to 0 when building gcc, will result in
an equally fscked stage3.

> > AIUI, the gcc make bootstrap NEVER claimed to be able to do this,
> > and in fact, has been known to fail starting from buggy compilers.
> 
> Proof please. I back up my arguments with facts.

It hasnt actually failed on /me/, but I have read of bootstrap failures
due to the host compiler on the gcc mailinglists.

Your argument ISNT backed by facts either. as far as I can tell, your
argument is: 'works for me'.

> Could you please do the same? Anything else is pure FUD.

Oh please. Im not a *complete* retard. Credit me *some* intelligence
please.

> > And I *asked* what the benefit is. I didnt denigrate anyones work,
> > and Im sorry if you read that into my words. dont read inbetween the
> > lines of text, theres nothing there.
> 
> Good :-)
> 
> > So, I'll ask again, more directly:
> > 
> > HOW does it garauntee that the compiler (and system) you build is
> > free from errors introduced by the host compiler?
> 
> It doesn't! One has to prove it!

Ok, so, having established that it doesnt garauntee the new compiler is
bug free (see, that wasnt so hard, was it?) can you please do what I
asked, and explain WHY it builds a better toolchain that the current
simple-yet-not-100%-efficient method does?

Does the current method not build repeatably for some reason? if so,
why?

> Which is what I've done. I could write a whole book on this subject
> (Ummm, I think I did - pure_lfs.txt:-)

So (again) is it *more* than just a way of avoiding compiling gcc twice?

> > As I said, ***AS I UNDERSTAND IT, AND I COULD BE WRONG***, you have
> > not proven it can build correctly from ANY host, just that it can
> > build repeatably without regression from YOUR host(s).
> 
> Dude, I do not have access to ANY host. That is a ridiculous
> proposition. If I did then I could guarantee it. Meanwhile back to
> reality..

Thanks. I was trying to make that clear to people, since you seemed to
imply (by fervently disagreeing with me before) that the pure-lfs build
method garaunteed a working stage3 no matter what. what you REALLY
garauntee is that (AFAICT) you have built an identical stage 2 and 3,
which is not quite the same.

> > I think an apology is in order...
> 
> I already said "sorry to be blunt" and I'm still "sorry to be blunt".

Thats not really an excuse, is it? you accused me (And again, this time,
actually) of spreading FUD, which you actually admit in this post (it
seems) is not FUD at all, in fact.
 
> When you've put as much work into this as Ryan and myself have, then
> have some apparently clueless person question your work WITHOUT ANY
> FACTS whatsoever then you'd react the same.

There you go again, (aparrently) Im still clueless and without facts. 

> Please present some facts to back up your arguments! It's not that
> hard.

FACT: regression tests only pick up changes. not pervasive b0rkenness.

simple, huh?

> Having said all that, as I've already mentioned, we do plan in the
> future to release a "LFS Build Verification Suite" which will just be
> a bunch of scripted stuff of which I've already written about i.e.
> just run the script then wake up in the morn' to check the diff's.
> Then you won't have to do the work that we've already done for you.

And *that* is the part of pure-lfs that I think is really an
achievement. its an impressive thing to have done. reducing the time
taken to build GCC is fine and fgreat, but the important thing is that
you provided a way of TESTING THAT IT WORKS, no matter how you actually
build it.

> Meanwhile, this childish bickering is stopping me from getting real
> work done so no more from me.

Whilst I do respect your work, I am less than impressed with you
personally right now. I still think you ought to apologise.
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list