Currently the build systems sets ARCH based on the result of 'uname -m'. On a mixed 32/64 system (one with a 64-bit kernel and a 32-bit userspace) this will result in "x86_64" which is wrong. We'd like the ARCH variable to represent the userspace we're compiling in/for, not what the kernel happens to be. Does anyone know of a clean way to detect this sort of system configuration? Thanks, Nick Lewycky
On 10/03/2009, at 1:25 PM, Nick Lewycky wrote:> Currently the build systems sets ARCH based on the result of 'uname - > m'. > On a mixed 32/64 system (one with a 64-bit kernel and a 32-bit > userspace) this will result in "x86_64" which is wrong. > > We'd like the ARCH variable to represent the userspace we're compiling > in/for, not what the kernel happens to be. > > Does anyone know of a clean way to detect this sort of system > configuration?Cleanest way is probably to explicitly test if __x86_64__ is defined, ie AC_COMPILE_IFELSE([AC_LANG_PROGRAM( [[#ifndef __x86_64__ error: Not x86-64 even if uname says so! #endif ]])], [ARCH=x86_64], [ARCH=i386]) Or in the alternative you can always key off sizeof(void *) == 8. Cheers, Nathan
Nathan Keynes wrote:> On 10/03/2009, at 1:25 PM, Nick Lewycky wrote: > >> Currently the build systems sets ARCH based on the result of 'uname - >> m'. >> On a mixed 32/64 system (one with a 64-bit kernel and a 32-bit >> userspace) this will result in "x86_64" which is wrong. >> >> We'd like the ARCH variable to represent the userspace we're compiling >> in/for, not what the kernel happens to be. >> >> Does anyone know of a clean way to detect this sort of system >> configuration? > > > Cleanest way is probably to explicitly test if __x86_64__ is defined, ie > > AC_COMPILE_IFELSE([AC_LANG_PROGRAM( > [[#ifndef __x86_64__ > error: Not x86-64 even if uname says so! > #endif > ]])], > [ARCH=x86_64], > [ARCH=i386])Fantastic, thank you! This is exactly the sort of thing I was looking for! I've applied this, basically verbatim, to LLVM's configure system in r66765. Nick