Brian Aker wrote: > On Sep 16, 2007, at 8:41 PM, James C. McPherson wrote: >> I am intrigued that are trying to do this. What benefits >> do you believe a automangled and libtoolised libdtrace >> would provide? > The standard skeleton we use for MySQL to build pluggable storage > engines uses libtool. The code fragment you saw was a breakdown of the > problem.
>> Ok, another question - since there is no port of DTrace for >> MS-Windows (at least, not that we know of) - why are you >> worrying about this now? > > The code normally compiles on Windows without any issue normally. The > include for unistd makes this an issue (though it is easy to get around > with a simple sed re-edit to the file). Its not about having DTrace one > Windows, its about using the null defines from the include file. This > would be easy enough if dtrace -h didn't add the unistd definition. > >> Probably due to a complete lack of desire to do so. >> I don't think there's anybody who really, seriously, >> thinks that doing what you propose is worth the effort. > > Thanks, but without figuring out a straightforward way of including this > it will make it questionable to use DTrace with MySQL storage engines. I > would think that there would be a way to make this work. I've got the > patch written for the core, but without figuring out the above we won't > be able to make much use of it. Thanks for explaining what you're getting at - I have to admit that I was quite concerned by your original email. Are you approaching this with the use of SDT probes, and which DTrace file are you referring to when you write "The Dtrace file isn't built" ? What sort of probes are you defining in skeleton_probes? Have you tried to #ifdef around the Solaris-specific definitions and inclusions? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems _______________________________________________ dtrace-discuss mailing list [email protected]
