On Jan 24, 2008 12:08 AM, Bruno Haible <[EMAIL PROTECTED]> wrote: > 3) On MacOS X 10.5 systems, "uname -m" returns "i386". But the system is > 64-bit, and "gcc -m64" generates x86_64 programs that run perfectly fine > natively. > > A user on such a platform struggled for *hours* to get a program compiled > with "gcc -m64", because in this situation, config.guess returns no > indication of a 64-bit CPU: > > [EMAIL PROTECTED]:~/devel/cln-1.2.0]$ export CC="gcc -m64" > [EMAIL PROTECTED]:~/devel/cln-1.2.0]$ sh autoconf/config.guess > i386-apple-darwin9.1.0 > > If config.guess returns such a result, it is really not obvious that the > user has to use > ./configure --host=x86_64-apple-darwin > in order to get the program compiled. > > Recall that this is a *native* build, not a cross build. I'd say, it's a > config.guess bug. config.guess should return "i386-apple-darwin9.1.0" if > the compiler generates 32-bit object code and should return > "x86_64-apple-darwin9.1.0" if the compiler generates 64-bit object code.
This approach seems eminently rational to me. 1. Systems on which the compiler generates 64-bit code will now appear to configure scripts as if they are indeed targeting a 64-bit system. 2. The user regains control over what kind of binary to build 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. James.
