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

[Robert Lipe]

Mike Hopkirk(hops) wrote:

> 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.

I posit that those building distributions are better qualified to
understand the issues involved and override the defaults than the
typical "download the tarball. type configure. type make" user.

> 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)

The official party line is that it runs on a 486.  (No, that isn't _my_
party line, either. :-) And if we accept that _most_ of the performance
conscious people are running P6 cores, we're impeding their performance
on the default case.  If we make the default P6, we completely break the
P5 users.

>      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

That's the bummer with doing it "our" way.

> 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

Sounds like we matched on this one.

> 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)

I'd agree.   But GCC is Really Important. :-)

> 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 ....

gcc/configure.in gets told "--target=blah".  From what I can see, it
doesn't know if 'blah' was created by the user (in which case override
would be evil) or by config.guess.  So having it second guess the
triplet sounds risky and like a maintenance problem; we're trying to
avoid the duplication by synching it against autoconf, not increase it.


> > 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

Yes, like OpenServer.   And like Linux.   What's good for the goose...

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

Oh, I'm playing both sides, too.    :-)

Earlier you said that GCC was the only package that _really_ cared about
the CPU field.  If we unlock it we have pathnames "floating" but things
are more likely to work better by default for more users of GCC.

Do the other packages ever have user-visible data (not private libs as
in the case of Perl or even GCC) that reflect this field?  If not, we're
no worse off than we are today where GCC's config.guess defaults to a
very different format on UW7 than the autoconf config.guess does.

I think we need to revisit the locked CPU decision.  Can you set up an
(internal) discussion on this?

RJL