Re: Why does config.guess come up with such wacky stuff?

["Mike Hopkirk(hops)" <hops at sco dot com>]

Well its a sort of philosphy thing - the open source philosohy is that you
build on what you run on ... Our experience has been that if you're building for
arbitrary distribution what you build on varies and this can cause 
architecture version dependency problems.

The rationale (not mine) I can remember for wiring it was
     a) UW7 only certified for Pentium or better so should be at least that
            ( whereas certified == runs adequately)

     b) desirable to have single cpu architecture value for all configured
         builds so that any systems that use it for 'where to put things'
         will end up using same place regardless of what they were built on

My opinion was that we should provide all the available info we can get and
let the builder or (app configuration override ) it if need be but that was
a minority opinion

OTOH I can make a case that if 
an app really cares about the specific architecture to build to 
(of which gcc is the only example to date) it should be defaulting to 
the widest coverage unless told different specifically or if it is going 
to assume you want the max optimisation oriented to the build platform it 
should be specifically checking for itself to override the guessed values ....


robertlipe@usa.net(Robert Lipe) wrote:

>  Without fretting over the
> details right now, would you support something like this in the master
> copy of config.guess so that GCC can use the master copy?
> 
> case `uname -X | egrep '^Machine` in
>         *i80486)   UNAME_MACHINE=i486;;
>         *Pentium$) UNAME_MACHINE=i586;;
>         *PentII*)  UNAME_MACHINE=i686;;
> esac

Like OSr5 does..
as I say my original opinion was that way - I was overruled 
(thats what you get when you ask for opinions)

Given that we've committed to wiring it already I'm loathe to change it again
for the general case.

Convince me its useful and won't cause work/problems 
for multiple widespread cases not just for gcc - I'll play devils advocate...



(I'm out the rest of this pm so followups may have to wait till tomorrow)

On Wed Dec 01,1999 (11:19:58AM -0600), robertlipe@usa.net(Robert Lipe) wrote:
> > > The code around line 3560 of configure.in handles this.  So now if
> > > you're on a 386 and type 'configure && make', GCC will presumably
> > > emit opcodes that your computer won't understand and generated
> > > binaries will crash.  If you're on a P-II or P-III and do the same,
> > > you're leaving clock cycles on the table becuase GCC is now "dumbed
> > > down" for a P5.  Neither of these are good.
> >
> > I see.
> 
> It wasn't that long ago (perhaps 2 years) that GCC ignored this anyway
> and none of the config.guesses knew how to grope the OS info.  So I
> suspect there are a number of people with cereberally cached copies of
> this.
> 
> This "problem" is compounded by GCC now actually caring about which of
> the IA32 brothers it's targeting.  Again, it wasn't that long ago that
> the target flags did little more than tinker with some alignment and
> padding and changed no actual opcode generation.


thats the real issue
 
> > This very situation comes up on Solaris/x86: config.guess always
> > prints i386-pc-solaris*, even though I'm running on a P-II.  It would
> > be nice to get this fixed too.
> 
> If you can figure out how to get the OS to tell you what processor you
> have, adding the bits to config.guess is easy.  There isn't a standard
> way of doing this, so it's quite OS-dependent.   There may be options to
> uname or sysinfo to tell you such things. 
> 
> Unfortunately, it isn't a win without costs.  Your Solaris case
> is a lovely example of the problem.  Experience has shown that
> people tend to trust config.guess and not override the result.  So
> right now, most of your installed GNU packages, libraries, and
> so on are probably in /usr/local/i386-mumble.  So if you have,
> say, a binary Perl distribution it's probably installed someplace
> /usr/local/lib/perl5/site_perl/*/i386-solarismumble.  If you change
> config.guess to be smarter for GCC's sake, you've now made the
> installation directory for other packages flail around.  So the perl
> libraries mention above move.

perl is a bad example for this ( while its oft cited as the classic case 
where this is needed) - it doesn't use autoconf/config.guess


> 
> If binary distributors had the discipline to force a consistent triplet
> for X86 where the value of 'X' doesn't really matter (I can't imagine
> Perl, for instance, caring) this would work out.  But that doesn't
> happen.
> 
> It's quite a mess, I fear...


-- 
- hops

Everything disclaimed (including disclaimer)
------<hops@sco.com>--------------------------------------
Mike Hopkirk (hops)  |       Whenever possible steal code.
SCO Inc              |          Tom Duff. (ex) Bell Labs