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
