Re: libtool and DTrace link steps

[Ralf Wildenhues]

* 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