You must augment the build process for your application to include the DTrace provider and probe definitions. A typical build process takes each source file and compiles it to create a corresponding object file. The compiled object files are then linked together to create the finished application binary, as shown in the following example:
cc -c src1.c cc -c src2.c ... cc -o myserv src1.o src2.o ...
To include DTrace probe definitions in your application, add appropriate Makefile rules to your build process to execute the dtrace command as shown in the following example:
cc -c src1.c cc -c src2.c ... dtrace -G -32 -s myserv.d src1.o src2.o ... cc -o myserv myserv.o src1.o src2.o ...
The dtrace command shown above post-processes the object files generated by the preceding compiler commands and generates the object file myserv.o from myserv.d and the other object files. The dtrace -G option is used to link provider and probe definitions with a user application. The -32 option is used to build 32–bit application binaries. The -64 option is used to build 64–bit application binaries.
If a user-land object contains a very large number of statically-defined probes then there may be a measurable delay when the object is first executed or loaded. If this is the case then one may use the lazyload option when building the object, for example,
dtrace -x lazyload -G ...
Objects built in this way do not advertise their probes to the kernel until required to do so. Thus,
dtrace -l | fgrep myserv
might not show any results until after running, for example,
dtrace -n myserv1203:::query-receive ...
or even just
dtrace -l -n myserv1203:::