HP UX Software Transition Kit (STK) Finding Object Library Ordering Relationships with lorder1

called, it is resolved from the explicitly-loaded library. But after running fastbind, the symbol foo() is resolved from the implicitly-loaded library. For more information about fastbind and how to improve program start-up time, see “Improving Shared Library Start-Up Time with fastbind” (page

222).

Example 10 Example

•To run fastbind on the executable file a.out: $fastbind a.out

•To later remove the fastbind information from the executable file a.out $fastbind -n a.out

Finding Object Library Ordering Relationships with lorder(1)

The lorder command finds the ordering relation for an object library. You can specify one or more object or archive library files (see ar(1)) on the command line or read those files from standard input. The standard output is a list of pairs of object file names, meaning that the first file of the pair refers to external identifiers defined in the second. You can process the output with tsort to find an ordering of a library suitable for one-pass access by ld (see tsort(1) and ld(1)). The linker ld is capable of multiple passes over an archive in the archive format and does not require that you use lorder when building an archive. Using the lorder command may, however, allow for a slightly more efficient access of the archive during the link-edit process. The symbol table maintained by ar allows ld to randomly access symbols and files in the archive, making the use of lorder unnecessary when building archive libraries (see ar(1)). The lorder command overlooks object files whose names do not end with .o, even when contained in library archives, and attributes their global symbols and references to some other file.

Example 11 Examples

•Build a new library from existing .o files:

$ar cr library `lorder *.o tsort`

•When creating libraries with so many objects that the shell cannot properly handle the *.o expansion, the following technique may prove useful:

$ls grep '.o$'lordertsortxargs ar cq library

Tracing Inter-Module Procedure Calls with ltrace(1)

The ltrace(1) command traces inter-module procedure calls. ltrace can be invoked as follows:

$ /usr/ccs/bin/ltrace [ltrace options] executable [-a <arguments to the executable>]

On executing the above command, a log is generated in the file logfile.txt in the current working directory. In case the log file already exists, it is appended with the output of the current ltrace invocation. For each call made in the application, the following line is added into the logfile:

lwp # <address>:<library>:<procedure>(<arguments>)

NOTE: The arguments are printed in the logfile only if a debug version of a library is being traced. To re-direct the output of the logfile.txt to an alternate file mylogfile, use the following command:

$/usr/ccs/bin/ltrace -f mylogfile ./a.out

In case of multiple invocations through the same command line, such as:

$ /usr/ccs/bin/ltrace ./a.out ./b.out

Finding Object Library Ordering Relationships with lorder(1) 67