[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool and DTrace link steps
From: |
Andreas Färber |
Subject: |
Re: libtool and DTrace link steps |
Date: |
Sat, 7 Jun 2008 13:36:22 +0200 |
Hello Ralf,
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
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.
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?
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 --
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?
Andreas