HP-UX Linker and Libraries User's Guide

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$'|lorder|tsort|xargs 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