* Andreas Färber wrote on Sat, Jun 07, 2008 at 01:36:22PM CEST: > Am 07.06.2008 um 03:35 schrieb Ralf Wildenhues: > >> Knowing diddly about DTrace, where's its documentation? > > The main DTrace resource is here: > http://www.opensolaris.org/os/community/dtrace/ > > A brief overview of the steps for Solaris 10 can be found here: > http://docs.sun.com/app/docs/doc/817-6223/chp-usdt?a=view
Thanks. > In short, on (Open)Solaris this step is required: > /usr/sbin/dtrace -32 -G -s theprovider.d -o generated.o obj1.o obj2.o ... > with -32 being a system-specific flag (-32/-64), theprovider.d a > project-specific input file, and *.o being object files with or without > probes but not yet touched by dtrace. > On Mac OS X this step does not apply, don't know about FreeBSD or QNX. This describes how things work when linking a program. There are at least two more cases to consider: - What if the program uses shared libraries? Do special measures have to be taken then, and if yes, what? (Consider the case of a pre-installed, third-party library.) - What if we create a shared library? Do special measures have to be taken then, and if yes, what? I suppose the name of the argument to 'dtrace -s' may be chosen freely, so naming it after the output file would probably be convenient. This problem looks like it applies not only to packages built with libtool, so ideally, some Automake support could be useful, too. But let's find out requirements first. >> Most likely >> trivial support can be had by writing a compiler/linker wrapper that >> runs dtrace programs as part of the build process. Anything more >> involved needs to know about semantics and command line interface. > > From libtool's output (1.5.22 on OpenSolaris 2008.05), it looks like > --mode=link would be a promising place to investigate? Looks like it. Please, before delving into the Libtool source, use a recent 2.2.x version, to save yourself and us the required porting. > Unfortunately I don't fully understand how it all fits together... > Libtool is being passed .lo and .la files and knows best how to get at > the .a and PIC/non-PIC .o files. Yet I don't see an argument to > differentiate shared, static and convenience library .la output for Shared libraries have nonempty library_names entries in the .la file, both shared and static libraries have a nonempty libdir entry, unlike convenience archives. > --tag=CC --mode=link (the dtrace -G step would only be necessary for a > shared library or executable as output). And looking closer I see that > despite extraction later on, it is passing .a files to gcc, which would > at least require making and using a temporary copy instead. > > Is all that logic somewhere in libltdl/config/ltmain.m4sh? Mostly. Most of the system-dependent logic is in libtool.m4, and is passed via variables at the beginning and end of the generated libtool script. Variables such as pic_flag (how to compile PIC code), archive_cmds (how to create a shared library), describe various specific tasks. The procedural part of libtool comes from ltmain.sh (which is generated in 2.2.x from ltmain.m4sh). One useful thing to look at here is how template instantiation is implemented for some C++ compilers (2.2.x only, not in 1.5.x) via the prelink_cmds variable. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
