ld.so.1(1) (man pages section 1: User Commands)

man pages section 1: User Commands

ld.so.1(1)

NAME

ld.so.1- runtime linker for dynamic objects

SYNOPSIS

/usr/lib/ld.so.1

/etc/lib/ld.so.1

DESCRIPTION

Dynamic applications consist of one or more dynamic objects. They are typically a dynamic executable and its shared object dependencies. As part of the initialization and execution of a dynamic application, an interpreter is called to complete the binding of the application to its shared object dependencies. In Solaris this interpreter is referred to as the runtime linker.

During the link-editing of a dynamic executable, a special .interp section, together with an associated program header, is created. This section contains a pathname specifying the program's interpreter. The pathname to the interpreter can be specified when the executable is being constructed by the -I option to ld(1) the link-editor. The default name supplied by the link-editor is that of the runtime linker, /usr/lib/ld.so.1.

During the process of executing a dynamic executable the kernel maps the file and locates the required interpreter. See exec(2) and mmap(2). The kernel maps this interpreter and transfers control to it, passing sufficient information to allow the interpreter to continue binding the application and then run it.

In addition to initializing an application, the runtime linker provides services that allow the application to extend its address space by mapping additional shared objects and binding to symbols within them.

The runtime linker performs the following functions:

It opens and processes any applicable configuration file. Configuration files may be employed to alter default search paths, provide a directory cache and provide alternative object dependencies. See crle(1). By default the configuration file /var/ld/ld.config is used for 32-bit objects and /var/ld/64/ld.config for 64-bit objects. Alternative configuration files can be specified with the LD_CONFIG environment variable, or encoded within a dynamic executable using the -c option of ld(1).
It analyzes the application's dynamic information section (.dynamic) and determines which shared object dependencies are required.
It locates and maps in these dependencies, and then it analyzes their dynamic information sections to determine if any additional shared object dependencies are required.
Once all shared object dependencies are located and mapped, the runtime linker performs any necessary relocations to bind these shared objects in preparation for process execution.
It calls any initialization functions provided by the shared object dependencies. By default these are called in the reverse order of the topologically sorted dependencies. Should cyclic dependencies exist, the initialization functions are called using the sorted order with the cycle removed. ldd(1) can be used to display the initialization order of shared object dependencies. See also LD_BREADTH.
It passes control to the application.
During the application's execution, the runtime linker can be called upon to perform any delayed function binding.
It calls any finalization functions on deletion of shared objects from the process. By default these are called in the order of the topologically sorted dependencies.
The application can also call upon the runtime linker's services to acquire additional shared objects by dlopen(3DL) and bind to symbols within these objects with dlsym(3DL)

Further details on each of the above topics may be found in the Linker and Libraries Guide

The runtime linker uses a prescribed search path for locating the dynamic dependencies of an object. The default search paths are the runpath recorded in the object, followed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-bit objects. This latter component can be modified using a configuration file created with crle(1). The runpath is specified when the dynamic object is constructed using the -R option to ld(1). LD_LIBRARY_PATH can be used to indicate directories to be searched before the default directories.

ENVIRONMENT VARIABLES

LD_AUDIT: A colon separated list of objects that will be loaded by the runtime linker. As each object is loaded, it will be examined for Link-Auditing interfaces; the routines that are present will be called as specified in the Link-Auditing interface described in the Linker and Libraries Guide. Also see the -p and -P options of ld(1).
LD_BIND_NOW: The runtime linker's default mode of performing lazy binding can be overridden by setting the environment variable LD_BIND_NOW to any non-null value. This setting causes the runtime linker to perform both data reference and function reference relocations during process initialization, before transferring control to the application. Also see the -z now option of ld(1).
LD_BREADTH: Any initialization functions are called reverse breadth-first order. Any finalization functions are called in breadth-first order.
LD_CONFIG: Provides an altenative configuration file. Configuration files may be employed to alter default search paths, provide a directory cache and provide alternate object dependencies. See crle(1).
LD_DEBUG: Provides a comma-separated list of tokens to cause the runtime linker to print debugging information to the standard error. The special token help indicates the full list of tokens available. The environment variable LD_DEBUG_OUTPUT may also be supplied to specify a file to which the debugging information is sent. The filename will be suffixed with the process id of the application generating the debugging information.
LD_FLAGS: Can take the values nolazyload or nodirect, which disable the lazy loading and direct binding of an object's dependencies for those objects that use these features.
LD_LIBRARY_PATH: The LD_LIBRARY_PATH environment variable, if set, is used to enhance the search path that the runtime linker uses to find dynamic dependencies. LD_LIBRARY_PATH specifies a colon-separated list of directories that are to be searched before the default directories. Also note that LD_LIBRARY_PATH adds additional semantics to ld(1).
LD_LIBRARY_PATH_64: Similar to the LD_LIBRARY_PATH environment variable. Overrides LD_LIBRARY_PATH for 64-bit dependencies.
LD_LOADFLTR: Filters are a form of shared object. They allow an alternative shared object to be selected at runtime and provide the implementation for any symbols defined within the filter. See the -f and -F options of ld(1). By default the alternative shared object processing is deferred until symbol resolution occurs against the filter. When LD_LOADFLTR is set to any non-null value, the runtime linker will process filters immediately when they are loaded. Also see the -z loadfltr option of ld(1).
LD_NOAUXFLTR: Auxiliary filters are a form of shared object. They allow an alternative shared object to be selected at runtime which provides the implementation for any symbols defined within the filter. See the -f option of ld(1). When LD_NOAUXFLTR is set to any non-null value, the runtime linker will disable this alternative shared object lookup.
LD_NOCONFIG: By default the runtime linker attempts to open and process a configuration file. When LD_NOCONFIG is set to any non-null value, the runtime linker will disable this configuration file processing.
LD_NODIRCONFIG: Provides a subset of LD_NOCONFIG in that any directory cache information provided in a configuration file is ignored.
LD_NOOBJALTER: Provides a subset of LD_NOCONFIG in that any alternative object dependencies provided in a configuration file are ignored.
LD_NOVERSION: By default the runtime linker verifies version dependencies for the primary executable and all of its dependencies. When LD_NOVERSION is set to any non-null value, the runtime linker will disable this version checking.
LD_ORIGIN: The immediate processing of $ORIGIN can be triggered by setting the environment variable LD_ORIGIN to any non-null value. This may be useful for applications that invoke chdir(2) prior to locating dependencies that employ the $ORIGIN string token.
LD_PRELOAD: Provides a whitespace-separated list of shared objects that are to be interpreted by the runtime linker. The specified shared objects are linked after the program is executed but before any other shared objects that the program references.
LD_PROFILE: Defines a shared object that will be profiled by the runtime linker. When profiling is enabled, a profiling buffer file is created and mapped. The name of the buffer file is the name of the shared object being profiled with a .profile extension. By default this buffer is placed under /var/tmp. The environment variable LD_ORIGIN_OUTPUT may also be supplied to indicate an alternative directory in which to place the profiling buffer. This buffer contains profil(2) and call count information similar to the gmon.out information generated by programs that have been linked with the -xpg option of cc. Any applications that use the named shared object and run while this environment variable is set will accumulate data in the profile buffer. The profile buffer information may be examined using gprof(1). Note that this profiling technique is an alternative to any that may be provided by the compilation system. The shared object being profiled does not have to be instrumented in any way, and LD_PROFILE should not be combined with a profile-instrumented application.

Note that environment variable names beginning with the characters 'LD_' are reserved for possible future enhancements to ld(1) and ld.so.1.

SECURITY

To prevent malicious dependency substitution or symbol interposition, some restrictions may apply to the evaluation of the dependencies of secure processes.

The runtime linker categorizes a process as secure if the user is not a super-user, and either the real user and effective user identifiers are not equal, or the real group and effective group identifiers are not equal. See getuid(2), geteuid(2), getgid(2), and getegid(2).

If an LD_LIBRARY_PATH environment variable is in effect for a secure process, then only the trusted directories specified by this variable will be used to augment the runtime linker's search rules. Presently, the only trusted directory known to the runtime linker is /usr/lib/secure, or /usr/lib/secure/sparcv9 for 64-bit SPARCV9 objects.

In a secure process, any runpath specifications provided by the application or any of its dependencies will be used, provided they are full pathnames, that is, the pathname starts with a '/'.

Additional objects may be loaded with a secure process using the LD_PRELOAD environment variable, provided the objects are specified as simple file names, with no '/' in the name. These objects will be located subject to the search path restrictions previously described.

FILES

/usr/lib/ld.so.1: Default runtime linker.
/etc/lib/ld.so.1: Alternate runtime linker.
/usr/lib/libc.so.1: Alternate interpreter for SVID ABI compatibility.
/usr/lib/ld.so: AOUT(BCP) runtime linker.
/usr/lib/0@0.so.1: Null character pointer compatibility library. See NOTES.
/usr/lib/secure: LD_PRELOAD location for secure applications.
/usr/lib/secure/sparcv9: LD_PRELOAD location for secure SPARCV9 applications.
/usr/lib/sparcv9/ld.so.1: Default runtime linker for the SPARCV9 architecture.
/usr/lib/sparcv9/0@0.so.1: Null character pointer compatibility library for the SPARCV9 architecture.
/var/ld/ld.config: Default configuration file for 32-bit applications..
/var/ld/sparcv9/ld.config: Default configuration file for SPARCV9 applications.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

NOTES

The user compatibility library /usr/lib/0@0.so.1 provides a mechanism that establishes a value of 0 at location 0. Some applications exist that erroneously assume a null character pointer should be treated the same as a pointer to a null string. A segmentation violation will occur in these applications when a null character pointer is accessed. If this library is added to such an application at runtime using LD_PRELOAD, it provides an environment that is sympathetic to this errant behavior. However, the user compatibility library is intended neither to enable the generation of such applications, nor to endorse this particular programming practice.

SunOS 5.8 Last Revised 2 Sept 1999