Re: config.guess and $CC

[Ron Garret]

On Jan 25, 2008, at 2:42 PM, Peter O'Gorman wrote:

> James Youngman wrote:
>
> > Maybe to save diagnostic effort in other quarters we should issue a
> > warning for the benefit of maintainers when we're overriding the
> > output of "uname -m".  One could hope that such warning messages  
> > would
> > get included in people's bug reports.  There is an argument for even
> > issuing a warning of a plan to change the behaviour without actually
> > channging it yet.  Unfortunately though, the percolation time on new
> > versions of config.guess is so long that we'd essentially be making
> > life hard for lots of users for quite a long time, in order to avoid
> > making life hard for a smaller number of maintainers for less time.
>
> I realize that it makes sense to have config.guess return
> x86_64-apple-darwin and ppc64-apple-darwin etc, and if such a change  
> is
> implemented there will be no need to print a warning because - it  
> makes
> sense.

I hope you don't mind if I chime in here.  I issue this disclaimer  
because I'm not a Gnu config user (except insofar as I use free  
software which uses Gnu config).  I'm just the person who first  
encountered the issue that led to Bruno to bring it to your attention.  
So if your reaction to what I'm about to say is, "He's an idiot who  
doesn't know what he's talking about" then you are very likely correct.

It seems to me that something very fundamental is being overlooked: if  
one compiles to 64-bit on a machine where uname -m outputs i386, that  
is *not* "overriding" uname -m.  The i386 architecture is NOT a 32-bit  
architecture, and it never was.  It was always a hybrid architecture.   
The Intel 80386 was able to run in both 16 and 32-bit modes.  But  
because Gnu/Linux never supported 16-bit mode, it had been safe to  
assume that i386 meant 32-bit.  But it was never *correct* to assume  
this.

The fundamental problem is that uname -m does not and CAN not contain  
enough information to decide which architecture to build for, because  
on a biarch system there are three different possibilities (32-bit, 64- 
bit and fat binary), and which one is right depends on the user's  
desires.  And, of course, it can get even worse than this if you start  
to support e.g. i386/PPC fat binaries.  OS X really blurs the  
boundaries between "native" and "cross" compilation.

It seems to me that the best solution would be if the config script  
could somehow automatically figure out all of the different modes that  
were supported on the current platform, and issue a message along the  
lines of:

"You are running on a system capable of natively generating binaries  
for the following machine architectures:

i386 32-bit
i386 64-bit
PowerPC 32-bit
PowerPC 64-bit

or any combination of the above.

Since you seem to actually be running on an i386 and your compiler by  
default seems to be producing 32-bit binaries, I'm going to build for  
i386 32-bit.  If that is not what you want, do the following..."

Or something like that.  It seems to me that would solve the problem  
in a way that was in some sense "backwards compatible" with the tacit  
i386=32-bit assumption.

I refer you again to the disclaimer that I opened with, and thank you  
for your attention.  (And the free software! :-)

rg