I am running a Snow Leopard: ~/box/valgrind$ uname -a Darwin MacBook-Pro-de-xxxxxx.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 ~/box/valgrind$ uname -s Darwin ~/box/valgrind$ uname -p i386 with valgrind svn trunk (r11206). I ran ./autogen.sh then ./configure, I found those lines about my system's architecure: checking build system type... i386-apple-darwin10.4.0 checking host system type... i386-apple-darwin10.4.0 checking for a supported CPU... ok (i386) checking for a 64-bit only build... no checking for a 32-bit only build... no checking for a supported OS... ok (darwin10.4.0) checking for the kernel version... Darwin 10.x (10.4.0) / Mac OS X 10.6 Snow Leopard and the final summary was: Maximum build arch: x86 Primary build arch: x86 Secondary build arch: Build OS: darwin Primary build target: X86_DARWIN Secondary build target: Default supp files: exp-ptrcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin10.supp So there would be only 32-bit x86 support. I then manually modified the generated configure: - host_cpu=$1 + host_cpu=x86_64 then the architeture lines became: checking for a supported version of gcc... ok (686) checking build system type... i386-apple-darwin10.4.0 checking host system type... i386-apple-darwin10.4.0 checking for a supported CPU... ok (x86_64) checking for a 64-bit only build... no checking for a 32-bit only build... no checking for a supported OS... ok (darwin10.4.0) checking for the kernel version... Darwin 10.x (10.4.0) / Mac OS X 10.6 Snow Leopard checking for a supported CPU/OS combination... ok (amd64-darwin) checking for use as an inner Valgrind... no and the summary lines were: Maximum build arch: amd64 Primary build arch: amd64 Secondary build arch: x86 Build OS: darwin Primary build target: AMD64_DARWIN Secondary build target: X86_DARWIN Default supp files: exp-ptrcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin10.supp And I have successfully compiled the source and my build of valgrind does support 32- and 64-bit executables.
If you run 'uname -a' on a 64-bit Mac you get this: Darwin wave 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 It claims to be 32-bit. I don't know why it is, but I think that's why autoconf thinks the machine is 32-bit. If you configure with --build=amd64-darwin it all works as expected. This is going to be a very FAQ if we don't do something about it, but I don't know what.
Isn't that because even 64 bit Mac's have a 32 bit kernel, and uname is reporting the kernel architecture?
At least on 10.5 and 10.6, it seems like the default XCode installation can build both 32- and 64-bit Valgrinds with no difficulty. So maybe we should just hardwire a biarch build by default?
I just updated the news item on www.valgrind.org to mention --build=amd64-darwin, which might reduce the F of the AQ until such time as we come up with a better solution.
(In reply to comment #3) > At least on 10.5 and 10.6, it seems like the default XCode > installation can build both 32- and 64-bit Valgrinds with > no difficulty. So maybe we should just hardwire a biarch > build by default? I think the very first Intel Macs had 32-bit only hardware. But if anyone is still using one of those they can use the --only-32bit option. So hardwiring a biarch build (however that is done) seems reasonable.
Can sysctl values be used? hw.cpu64bit_capable: 1 hw.optional.x86_64: 1 machdep.cpu.extfeatures: SYSCALL XD EM64T LAHF Some people uses nvram boot-args with "arch=i386" to boot Snow Leopard in 32-bit mode (I know it is rare :), so perhaps compiling a simple C program with '-m64' and test if the output is runnable is more safer to determine the architecture.
Always building 32- and 64-bit is the way to go. If you wanted to be paranoid, you could build 32+64 unless the system is incapable of building 64-bit. I'd ignore the ability of the system to run either.
In r11208 I changed configure.in to just change x86-darwin to amd64-darwin. Should be good enough, AFAICT. If anyone has any better ideas feel free to reopen the bug.
I am maintaining valgrind in MacPorts. I've got a report that valgrind cannot be executed on a Mac with a CoreDuo (32-bit only) processor: http://trac.macports.org/ticket/25684 This is against r11208 from trunk, you can find the config.log attached there. Does this override from x86-darwin to amd64-darwin mean that it supports both 32 and 64-bit, but the executable is always for the primary arch only?
(In reply to comment #9) Rainer, > Does this override from x86-darwin to amd64-darwin mean that it supports both > 32 and 64-bit, but the executable is always for the primary arch only? Hmm, there are multiple executables, but the "launcher" ($prefix/bin/valgrind) is always for the primary arch. So in this case it is hardwired for x86_64-darwin. Perhaps your users could in this situation get a 32-bit only build using one or both of the flags --build=x86-darwin or --enable-only32bit I haven't tried (and I don't have a 32-bit only Mac to try with), but it's perhaps worth propagating this suggestion to http://trac.macports.org/ticket/25684.