Am 02.07.2008 um 08:22 schrieb James McIlree: > On Jul 1, 2008, at 10:57 PM, Domas Mituzas wrote: > >> 2. Lack of -G makes various software not working. Both MySQL and >> PECL's dtrace use it, instead of relying on generated .h files. > > This is the source of some debate between Adam and I :-). We're > planning to add a -G no-op flag so builds don't fall over, but we have > no plans to ever support the old DTRACE_PROBE macros.
To add to that debate, I recently added USDT probes to the Mono runtime (http://www.mono-project.com). On Mac OS X, this was really easy. The dtrace -G for Solaris however does not play nice with GNU automake and libtool. Thus, I would rather prefer if Sun would drop dtrace -G like Apple did. But since that is unlikely to happen, it would be nice if Sun/Apple could contribute support for dtrace -G to those relatively common open source build tools, to facilitate adoption of DTrace. The problem is that the .o files to pass to dtrace -G are hidden either behind .lo files pointing to PIC and non-PIC .o files, or in .a files hidden behind a .la file. Further problems arise from the coexistence of PIC and non-PIC versions of the same object file and the usage patterns of the .la libraries (object files might be shared by multiple .la libraries and/or executables, so the original .o files can't be modified or subsequent builds of other components would break for non- no-op dtrace -G). I came up with this dirty hack: http://anonsvn.mono-project.com/viewcvs/trunk/mono/dtrace-prelink.sh?view=markup A clean solution is to either drop dtrace -G on every platform or to add proper tool support for dtrace -G. I inquired with the libtool developers and they would be interested in patches, but I'm still pretty lost as to how to go about that myself. Andreas _______________________________________________ dtrace-discuss mailing list [email protected]
