On Jan 25, 2008 11:30 PM, Ron Garret <[EMAIL PROTECTED]> wrote: > 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.
Actually you *can* build 16-bit x86 code with GCC. Very carefully. See http://sourceware.org/binutils/docs-2.17/as/i386_002d16bit.html for the horrid details. > The fundamental problem is that uname -m does not and CAN not contain > enough information to decide which architecture to build for, Yes, that's why we should be trusting $CC, if it was specified. This was pointed out in Bruno's original email. I guess part of the difficulty though is that there are a number of things we can't always discover simply by using a compilation test. I can't comment in detail on the use of config.guess that originated the discussion though; I haven't used CLN much since about 1995. > 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. The normal convention is to assume that the user made any choice they wanted through possibly setting $CC and using the --host and --build options to configure. Essentially the output of config.guess is for setting the default used if those options weren't given. Part of the problem though is that when these automated guesses give an answer which isn't what the user wanted, the configure script doesn't indicate there's an alternative and doesn't stop to explain how to select it. Since alternatives aren't suggested, those alternatives aren't widely used. Not-widely-used alternatives aren't well tested by users, and so can fail to work more than the well-tested options. It's unfortunate. Many maintainers (and particularly Bruno, I notice) try to combat this by building on many different kinds of systems. Thanks, James.
