This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: config.guess and Linux/GNU
- To: Franz dot Sirl-kernel at lauterbach dot com, bkorb at sco dot COM
- Subject: Re: config.guess and Linux/GNU
- From: Mike Stump <mrs at windriver dot com>
- Date: Mon, 12 Jun 2000 15:17:14 -0700 (PDT)
- Cc: bje at redhat dot com, config-patches at gnu dot org, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, mark at codesourcery dot com, martin at loewis dot home dot cs dot tu-berlin dot de
> Date: Sun, 11 Jun 2000 12:04:33 -0700
> From: Bruce Korb <bkorb@sco.COM>
> Organization: Santa Cruz Operations
> No, wrong, do *not* delete the "elf_i?86" entry.
Hog wash. As the author of config.guess let me sed some light. If
the code was broken, bug fix it, without introducing new bugs. If you
introduce new bugs, then to prevent bug pushing, which doesn't help
anyone, we should be allowed to demand the removal of the new breakage
to restore how it used to work. If you're unable to bug fix it
(monotonically better), then hopefully someone else can, or provide
enough of a clue to get you going in the right direction.
Also, one need not run cc, if there are other ways to find that
information. if [ -f /usr/include/newfile.h ] will find it equally
well (or better), then one might be tempted to use it.
> It turns out that the rest of the config.guess script depends upon
> "cc" doing the "right thing", which aint necessarily so.
We can see if cc does the right thing, and when it doesn't, then do as
you suggest.
The short of this is simple, we believe the code is wrong, you must
fix it. It is less important exactly how you fix it, as long as it is
fixed. The details matter not quite as much. Do you agree the code
is wrong? If it is, explain how you'r going to fix it. If you don't
want to, then reverting a bad bug fix, is reasonable.