library specified on the linker command line: because the other libraries preceding it in the link order often contain references to libc routines and so must precede it.

NOTE: If multiple definitions of a symbol occur in the specified libraries, ld does not necessarily choose the first definition. It depends on whether the program is linked with archive libraries, shared libraries, or a combination of both. Depending on link order to resolve such library definition conflicts is risky because it relies on undocumented linker behavior that may change in future releases. (See also “Caution When Mixing Shared and Archive Libraries” (page 118).)

Running the Program

•“Loading Programs: exec” (page 25)

•“Binding Routines to a Program” (page 25)

•“Deferred Binding is the Default” (page 25)

An executable file is created after the program has been compiled and linked. The next step is to run or load the program.

Loading Programs: exec

When you run an executable file created by ld, the program is loaded into memory by the HP-UX program loader, exec. This routine is actually a system call and can be called by other programs to load a new program into the current process space. The exec function performs many tasks; some of the more important ones are:

•Determining how to load the executable file by looking at its magic number. (See also“The a.out File” (page 22).)

•Determining where to begin execution of the program - that is, the entry point - For examples in share-bound executables in dld.so, in archive-bound executables in crt0.o. (See also “The crt0.o Startup File” (page 21).)

•When the program uses shared libraries, the crt0.o startup code invokes the dynamic loader, which in turn attaches any required shared libraries. If immediate binding was specified at link time, then the libraries are bound immediately. If deferred binding was specified, then libraries are bound as they are referenced. (See also “What are Shared Libraries?” (page 91).)

For details on exec, see the exec(2) page in the HP-UX Reference.

Binding Routines to a Program

Since shared library routines and data are not actually contained in the a.out file, the dynamic loader must attach the routines and data to the program at run time. Attaching a shared library entails mapping the shared library code and data into the process's address space, relocating any pointers in the shared library data that depend on actual virtual addresses, allocating the bss segment, and binding routines and data in the shared library to the program.

The dynamic loader binds only those symbols that are reachable during the execution of the program. This is similar to how archive libraries are treated by the linker; namely, ld pulls in an object file from an archive library only if the object file is needed for program execution.

Deferred Binding is the Default

To accelerate program startup time, routines in a shared library are not bound until referenced. (Data items are always bound at program startup.) This deferred binding of shared library routines distributes the overhead of binding across the execution time of the program and is especially expedient for programs that contain many references that are not likely to be executed. In essence, deferred binding is similar to demand-loading.

Running the Program 25