This morning I merged the DARWIN branch, which had been holding Valgrind’s support for Mac OS X, onto the trunk. The branch is now defunct, and Valgrind-on-Mac users should check out the trunk like so:
svn co svn://svn.valgrind.org/valgrind/trunk <dirname> cd <dirname>
and then build it according to the instructions in the README file.
This is a good thing, if only because it means I can spend less time maintaining a branch and more time actually fixing things.
Update: fixed the svn URL.
17 replies on “Mac OS X now supported on the Valgrind trunk”
Awesome!
Will you be doing a WWDC presentation on Valgrind?
And can you coax Greg into updating
http://www.sealiesoftware.com/valgrind ?
Dan,
No WWDC presentation is planned, sorry.
I’ll aks Greg to update his page. It’s a good idea, it is the top hit if you google for “valgrind mac”.
That’s great news! Any ETA for a release? I ask because I’d like to package Valgrind for Fink (http://www.finkproject.org/), and the packaging policy requires a numbered release with downloadable source tarball.
Works great. Well done Nicholas.
Steve,
Not sure about a release date, it’ll probably be a few months though. One consideration is that Mac OS 10.6 is likely to come out it June. 10.5 is 64-bit capable but uses 32-bit programs by default. 10.6 will apparently use 64-bit programs by default. And Valgrind’s 64-bit Darwin support is not as good as the 32-bit support, so some work will be necessary there.
Re the earlier post about iTunes – it’ll probably start up, but QuickTime needs aio_* for file access, which isn’t implemented. Other than that, it’s great work and I’m using it constantly.
Awesome work! 32-bit off the trunk works great for me. I’m eagerly awaiting full 64-bit support!
Eric B, if you configure it with –build=amd64-darwin then it will run both 32-bit and 64-bit executables. The 64-bit support is not as complete, though, and quite slow to start up.
There will be WWDC presentations on the Clang Static Analyzer, but not Valgrind. (Valgrind and Clang Static Analyzer: two great tastes that taste great together!) If you have Valgrind questions, I’ll be in the labs at various times during the week.
gcc -arch i386 -O2 -g -Wmissing-prototypes -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -mmacosx-version-min=10.5 -fno-stack-protector -mdynamic-no-pic -O2 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -nodefaultlibs -nostartfiles -Wl,-u,__start -Wl,-e,__start -Wl,-bind_at_load /usr/lib/dyld -arch i386 -Wl,-seg1addr,0xf0080000 -Wl,-stack_addr,0xf0080000 -Wl,-stack_size,0x80000 -Wl,-pagezero_size,0xf0000000 -o memcheck-x86-darwin memcheck_x86_darwin-mc_leakcheck.o memcheck_x86_darwin-mc_malloc_wrappers.o memcheck_x86_darwin-mc_main.o memcheck_x86_darwin-mc_translate.o memcheck_x86_darwin-mc_machine.o memcheck_x86_darwin-mc_errors.o ../coregrind/libcoregrind-x86-darwin.a ../VEX/libvex-x86-darwin.a -lgcc
ld: in ../VEX/libvex-x86-darwin.a, archive has no table of contents
collect2: ld returned 1 exit status
🙁
bc, can you file a bug report? http://bugs.kde.org/enter_valgrind_bug.cgi
Thanks.
I have tried DARWIN branch a few times(for different revisions). Every time I can compile it , but running it always results to Trace/BPT trap.Today I checkout from trunk, and I get the same result.
my environment:
10.5.7 -uname- Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386
gcc version 4.0.1 (Apple Inc. build 5490)
Anyone else has trouble like me?
agilesoftware, it may well be due to https://bugs.kde.org/show_bug.cgi?id=193917. If so, it’s not Valgrind’s fault and there’s an easy workaround.
It works for me. Thank you very much.
But I always get:
valgrind: m_libcfile.c:73 (vgPlain_safe_fd): Assertion ‘newfd >=
VG_(fd_hard_limit)’ failed.
I have reported it on http://bugs.kde.org/show_bug.cgi?id=196335
Great stuff!
Missing ppc32-darwin support, though… 🙁
But then again, come September and 10.6, my trusty G4 will probably R.I.P. anyway. 🙂
Thanks!
Mike,
Greg Parker, who wrote the port, initially started with ppc32-darwin, because he started it before x86-darwin machines even existed. But he switched to x86-darwin when it became clear that PPC was on the way out.
Porting Valgrind to any new platform — even if the architecture and OS have been handled in other supported combinations — is a lot of work, and so the cost/benefit ratio for ppc32-darwin is really unfavourable.