Hi Brian, Brian Aker wrote: > I am trying to work dtrace into a library created with automake and > libtool.
I am intrigued that are trying to do this. What benefits do you believe a automangled and libtoolised libdtrace would provide? > I've been playing with this all afternoon but I've hit a wall > on making the following work: > > noinst_HEADERS = ha_skeleton.h \ > �� � � � � � � � skeleton_probes.h > > lib_LTLIBRARIES = libskeleton_engine.la > libskeleton_engine_la_SOURCES = ha_skeleton.cc skeleton_probes.d > > I've added the following suffix rule and header builder: > > skeleton_probes.h: skeleton_probes.d > �� � � �$(DTRACE) $(DTRACEFLAGS) -h -s skeleton_probes.d > �� � � �mv skeleton_probes.h skeleton_probes.h.bak > �� � � �sed "s/#include <unistd.h>//g" skeleton_probes.h.bak > > skeleton_probes.h > �� � � �rm skeleton_probes.h.bak > > SUFFIXES : .d > > .d.o : $(DTRACEFILES) > �� � � �$(DTRACE) $(DTRACEFLAGS) -G -s $< $(DTRACEFILES) > > The "sed" has to be done to keep the port working on windows (which > lacks the unistd.h that is generated by the dtrace -h). It would be nice > to see dtrace fixed so that portability was a bit easier. 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? What sort of fixing of DTrace do you have in mind to make it more portable? Are you aware of how deeply into the kernel DTrace has its hooks? > The problem? The Dtrace file isn't built. The fault is more in mine in > not being able to get automake to do what it should be able to do, but > when looking around the net I've not found where anyone else has gotten > dtrace to work with libtool libraries either. 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. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems _______________________________________________ dtrace-discuss mailing list [email protected]
