HP UX Software Transition Kit (STK) manual Not Recording Link Time Paths with +nodefaultrapth

if a definition exists outside the program file. In such cases, a shared library may update a global variable needed by the program, but the program would never see the change because it is referencing its own copy.

One example of a data symbol that should almost always be exported from a program is errno. The errno data symbol is defined in every shared library and program; if this definition is hidden, the value of errno is not shared outside of the program in which it is hidden.

In IPF/PA-64 mode, the behavior specified by -Eis the default behavior.

Not Recording Link Time Paths with +nodefaultrapth

By default, the linker records the link time paths of dependent shared libraries in the resultant executables and shared libraries. In 32-bit mode, link time paths are recorded as a part of the library name in the shared library list. In 64-bit mode, link time paths are recorded as embedded path (unless embedded path is defined explicitly using +b option).

The linker can be told not to record any link time paths by specifying the +nodefaultrpath option at link time. This option applies only to libraries specified with -lon the linker command line (for example, -lfoo). Link time paths will still be recorded for libraries whose full path name is specified (for example, /usr/contrib/lib/libfoo.sl) on the link line.

By default (i.e., if no other paths are specified) the 32 bit dld.sl searches for libraries in the current directory and the 64 bit dld.sl searches in the /lib/pa20_64 and /usr/lib/pa20_64 directories. So if +nodefaultrpath is specified at link time and the application needs libraries that are not present in above paths, care must be taken to provide the paths of these libraries using either SHLIB_PATH, LD_LIBRARY_PATH or embedded path.

Moving Libraries after Linking with +b

A library can be moved even after an application has been linked with it. This is done by providing the executable with a list of directories to search at run time for any required libraries. One way you can store a directory path list in the program is by using the +b path_list linker option.

Note that dynamic path list search works only for libraries specified with -lon the linker command line (for example, -lfoo). It does not work for libraries whose full path name is specified (for example, /usr/contrib/lib/libfoo.sl). However, it can be enabled for such libraries with the -loption to the chatr command (see “Changing a Program's Attributes with chatr(1)” (page

53)).

Specifying a Path List with +b

The syntax of the +b option is:

+b path_list

where path_list is the list of directories you want the dynamic loader to search at run time. For example, the following linker command causes the path .:/app/lib to be stored in the executable. At run time, the dynamic loader searches for libfoo, libm, and libc in the current working directory (.), and then in the directory /app/lib

$ ld /opt/langtools/lib/crt0.o +b .:/app/lib prog.o -lfoo -lm -lc

If path_list is only a single colon, the linker constructs a path list consisting of all the directories specified by -L, followed by all the directories specified by the LPATH environment variable. For instance, the following linker command records the path list as /app/lib:/tmp:

$ LPATH=/tmp ; export LPATH

$ ld /opt/langtools/lib/crt0.o +b : -L/app/lib prog.o -lfoo -lm -lc

On PA32 systems, if multiple +b options appear on the link line, the output file records the +b option that is specified first.

Using Linker Commands 41