HP UX Software Transition Kit (STK) manual Ldpreload Example

Loading Shared Libraries with the LD_PRELOAD Environment Variable

NOTE: The LD_PRELOAD feature is disabled for seteuid/setegid programs, such as passwd. See ld(1) for more details. This feature is not available for fully-bound static executables.

The LD_PRELOAD environment variable allows you to load additional shared libraries at program startup. The LD_PRELOAD environment variable provides a colon-separated or space-separated list of shared libraries that the dynamic loader can interpret. The dynamic loader, dld.so, loads the specified shared libraries as if the program is linked explicitly with the shared libraries in LD_PRELOAD before any other dependents of the program.

At startup time, the dynamic loader implicitly loads one or more libraries, if found, specified in the LD_PRELOAD environment. It uses the same load order and symbol resolution order as if the library is explicitly linked as the first library in the link line when building the executable. For example, given an executable built with the following link line:

$ ld ... lib2.so lib3.so lib4.so

If LD_PRELOAD="/var/tmp/lib1.so", the dynamic loader uses the same load order and symbol resolution order as if lib1.so is specified as the first library in the link line:

$ ld ... /var/tmp/lib1.so lib2.so lib3.so lib4.so

In a typical command line use (with /usr/bin/sh), whereLD_PRELOAD is defined as follows:

$ LD_PRELOAD=mysl.so application

The dynamic loader searches application according to $PATH, but searches mysl.so according to SHLIB_PATH and/or LD_LIBRARY_PATH, and/or the embedded path (if enabled).

You can use the LD_PRELOAD environment variable to load a shared library that contains thread-local storage to avoid the following error when loading the library dynamically:

/usr/lib/hpux32/dld.so: Cannot dlopen load module /usr/lib/hpux32/libpthread.so.1

The dynamic loader uses the LD_PRELOAD environment variable even if you use the +noenvvar option in the link line. This ensures that LD_PRELOAD is enabled even in a +compat link. The LD_PRELOAD variable is always enabled except for setuid and setgid programs.

NOTE: Using LD_PRELOAD can cause a core dump when used with applications which mix shared and archived libraries, especially when both the shared library and the application are built with aC++ or use libc.

You can specify multiple libraries as part of the LD_PRELOAD environment variable. Separate the libraries by spaces or colons as in LD_LIBRARY_PATH. (Multi-byte support is not provided as part of parsing the LD_PRELOAD library list). You can specify LD_PRELOAD libraries with absolute paths or relative paths. The LD_PRELOAD libraries can also consist of just the library names, in which case the dynamic loader uses the directory path list in the environment variables LD_LIBRARY_PATH and/or SHLIB_PATH or the embedded path list (if enabled) to search for the libraries.

The dynamic loader does not issue an error or warning message if it cannot find a library specified by LD_PRELOAD. However, if it does not find a dependent of the LD_PRELOAD libraries, the dynamic loader issues the same error message as if the LD_PRELOAD library is specified in the link line.

LD_PRELOAD Example

Consider a case where a.out has the following dependents:

a.out

/\

libA.so libB.so

That is, a.out is built with commands like these:

Creating Shared Libraries 103