Richard B. Kreckel wrote:
Regarding the __i386__ definition: There is code in m4/general.m4 that ought to correct the misleading uname -m output if kernelland is 64 bit and userland 32 bit. It's worked for others so far. Why does it fail for Ron?
It fails for Ron because his 'uname -m' result does not indicate a 64-bit CPU. This should fix it. Committed. 2007-01-23 Bruno Haible <bruno@clisp.org> Allow 64-bit builds on MacOS X 10.5. * m4/general.m4 (CL_CANONICAL_HOST_CPU): Test for x86_64 CPU if "uname -m" returns "i386". Reported by Ron Garret <ron@flownet.com>. *** m4/general.m4 18 Dec 2007 23:01:19 -0000 1.4 --- m4/general.m4 23 Jan 2008 12:05:00 -0000 *************** *** 1,4 **** ! dnl Copyright (C) 1993-2006 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program --- 1,4 ---- ! dnl Copyright (C) 1993-2008 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program *************** *** 184,192 **** host_cpu=sparc fi ;; dnl AMD64 running Linux have 'uname -m' = "x86_64" even if userland is purely dnl 32-bit. ! x86_64 ) AC_CACHE_CHECK([for 64-bit userland on x86-64], cl_cv_host_x86_64, [ AC_COMPILE_IFELSE([AC_LANG_PROGRAM( [[#if !defined __x86_64__ --- 184,194 ---- host_cpu=sparc fi ;; + dnl MacOS X 10.5 machines on x86_64 platforms have 'uname -m' = "i386" even + dnl if 64-bit programs are fully supported. dnl AMD64 running Linux have 'uname -m' = "x86_64" even if userland is purely dnl 32-bit. ! i386 | x86_64 ) AC_CACHE_CHECK([for 64-bit userland on x86-64], cl_cv_host_x86_64, [ AC_COMPILE_IFELSE([AC_LANG_PROGRAM( [[#if !defined __x86_64__