Now that Mac OS X 10.5 includes support for dtrace, we should support building with dtrace enabled on that OS. According to Adam Leventhal in a blog post <http://blogs.sun.com/ahl/entry/dtrace_firefox_leopard>, it's not too tricky, and he has a patch. Ryan Flint also has a patch <http://screwedbydesign.com/mozilla/dtracemac.diff>.
Ryan's patch looks good; just two comments: It seems like it would be a good idea to change the polarity of the condition (if !MACOSX) since FreeBSD and other ports are, I'd argue, likely to be in the model of Solaris _and_ Mac OS X will hopefully implement -G at least as a no-op (apple bug <rdar://problem/5566030>). I think it's worth noting in the change to the provider D file that it's a work around for apple's bugs: <rdar://problem/5194316> <rdar://problem/5565198>
Created attachment 286883 [details] [diff] [review] Patch Same patch with Adam's comments addressed.
Created attachment 286886 [details] [diff] [review] The right patch Bah, It'd probably be helpful if I gave these unique names before attaching them.
Comment on attachment 286886 [details] [diff] [review] The right patch I can't say I fully understand how DTrace works, but this just comments out the calls to dtrace from the build process. What are we losing from that?
The calls eliminated are superfluous on Leopard (needed by Solaris)
Comment on attachment 286886 [details] [diff] [review] The right patch Drivers: this is a nearly zero risk patch (only changes code built with --enable-dtrace) that will allow our developers and others on Leopard to utilize DTrace - which is immensely useful for our ongoing performance efforts.
Comment on attachment 286886 [details] [diff] [review] The right patch a+ as we don't ship with --enable-dtrace by default (thus NPOTDB) but useful for devs anyway