Summary: | valgrind 3.6.0 svn failed to be built with x86_64 | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | 191919 |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gparker, njn, raimue, tom |
Priority: | NOR | ||
Version: | 3.6 SVN | ||
Target Milestone: | blocking3.6.0 | ||
Platform: | Unlisted Binaries | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: |
Description
191919
2010-07-01 17:36:43 UTC
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. |