LD(1) User Commands LD(1) NNAAMMEE ld - link-editor for object files SSYYNNOOPPSSIISS lldd [--3322 | --6644] [--aa | --rr] [--bb] [--BBdirect | nodirect] [--BB dynamic | static] [--BB eliminate] [--BB group] [--BB local] [--BB reduce] [--BB symbolic] [--cc _n_a_m_e] [--CC] [--dd y | n] [--DD _t_o_k_e_n,...] [--ee _e_p_s_y_m] [--ff _n_a_m_e | --FF _n_a_m_e] [--GG] [--hh _n_a_m_e] [--ii] [--II _n_a_m_e] [--ll _x] [--LL _p_a_t_h] [--mm] [--MM _m_a_p_f_i_l_e] [--NN _s_t_r_i_n_g] [--oo _o_u_t_f_i_l_e] [--pp _a_u_d_i_t_l_i_b] [--PP _a_u_d_i_t_l_i_b] [--QQ y | n] [--RR _p_a_t_h] [--ss] [--SS _s_u_p_p_o_r_t_l_i_b] [--tt] [--uu _s_y_m_n_a_m_e] [--VV] [--YY PP_,_d_i_r_l_i_s_t] [--zz absexec] [--zz allextract | defaultextract | weakextract ] [--zz altexec64] [--zz aslr[=_s_t_a_t_e]] [--zz assert-deflib] [ --zz assert-deflib=_l_i_b_n_a_m_e] [--zz combreloc | nocombreloc ] [--zz defs | nodefs] [--zz direct | nodirect] [--zz endfiltee] [--zz fatal-warnings | nofatal-warnings ] [--zz finiarray=_f_u_n_c_t_i_o_n] [--zz globalaudit] [--zz groupperm | nogroupperm] [--zz guidance[=_i_d_1,_i_d_2...] [--zz help ] [--zz ignore | record] [--zz initarray=_f_u_n_c_t_i_o_n] [--zz initfirst] [--zz interpose] [--zz lazyload | nolazyload] [--zz ld32=_a_r_g_1,_a_r_g_2,...] [--zz ld64=_a_r_g_1,_a_r_g_2,...] [--zz loadfltr] [--zz muldefs] [--zz nocompstrtab] [--zz nodefaultlib] [--zz nodelete] [--zz nodlopen] [--zz nodump] [--zz noldynsym] [--zz nopartial] [--zz noversion] [--zz now] [--zz origin] [--zz preinitarray=_f_u_n_c_t_i_o_n] [--zz redlocsym] [--zz relaxreloc] [--zz rescan-now] [--zz recan] [--zz rescan-start _._._. --zz rescan-end]] [--zz target=sparc|x86] [--zz text | textwarn | textoff] [--zz verbose] [--zz wrap=_s_y_m_b_o_l] _f_i_l_e_n_a_m_e... DDEESSCCRRIIPPTTIIOONN The link-editor, lldd, combines relocatable object files by resolving symbol references to symbol definitions, together with performing relocations. lldd operates in two modes, static or dynamic, as governed by the --dd option. In all cases, the output of lldd is left in the file aa..oouutt by default. See NOTES. In dynamic mode, --ddyy, the default, relocatable object files that are provided as arguments are combined to produce an executable object file. This file is linked at execution with any shared object files that are provided as arguments. If the --GG option is specified, relocatable object files are combined to produce a shared object. Without the --GG option, a dynamic executable is created. In static mode, --ddnn, relocatable object files that are provided as arguments are combined to produce a static executable file. If the --rr option is specified, relocatable object files are combined to produce one relocatable object file. See SSttaattiicc EExxeeccuuttaabblleess. Dynamic linking is the most common model for combining relocatable objects, and the eventual creation of processes within Solaris. This environment tightly couples the work of the link-editor and the runtime linker, lldd..ssoo..11(1). Both of these utilities, together with their related technologies and utilities, are extensively documented in the _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. If any argument is a library, lldd by default searches the library exactly once at the point the library is encountered on the argument list. The library can be either a shared object or relocatable archive. See aarr..hh(3HEAD)). A shared object consists of an indivisible, whole unit that has been generated by a previous link-edit of one or more input files. When the link-editor processes a shared object, the entire contents of the shared object become a logical part of the resulting output file image. The shared object is not physically copied during the link-edit as its actual inclusion is deferred until process execution. This logical inclusion means that all symbol entries defined in the shared object are made available to the link-editing process. See Chapter 4, _S_h_a_r_e_d _O_b_j_e_c_t_s_, in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e For an archive library, lldd loads only those routines that define an unresolved external reference. lldd searches the symbol table of the archive library sequentially to resolve external references that can be satisfied by library members. This search is repeated until no external references can be resolved by the archive. Thus, the order of members in the library is functionally unimportant, unless multiple library members exist that define the same external symbol. Archive libraries that have interdependencies can require multiple command line definitions, or the use of one of the --zz rreessccaann options. See _A_r_c_h_i_v_e _P_r_o_c_e_s_s_i_n_g in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. lldd is a cross link-editor, able to link 32-bit objects or 64-bit objects, for Sparc or x86 targets. lldd uses the EELLFF class and machine type of the first relocatable object on the command line to govern the mode in which to operate. The mixing of 32-bit objects and 64-bit objects is not permitted. Similarly, only objects of a single machine type are allowed. See the --3322, --6644 and --zz ttaarrggeett options, and the LLDD__NNOOEEXXEECC__6644 environment variable. SSttaattiicc EExxeeccuuttaabblleess The creation of static executables has been discouraged for many releases. In fact, 64-bit system archive libraries have never been provided. Because a static executable is built against system archive libraries, the executable contains system implementation details. This self-containment has a number of drawbacks. o The executable is immune to the benefits of system patches delivered as shared objects. The executable therefore, must be rebuilt to take advantage of many system improvements. o The ability of the executable to run on future releases can be compromised. o The duplication of system implementation details negatively affects system performance. With Solaris 10, 32-bit system archive libraries are no longer provided. Without these libraries, specifically lliibbcc..aa, the creation of static executables is no longer achievable without specialized system knowledge. However, the capability of lldd to process static linking options, and the processing of archive libraries, remains unchanged. OOPPTTIIOONNSS The following options are supported. --3322 | --6644 Creates a 32-bit, or 64-bit object. By default, the class of the object being generated is determined from the first EELLFF object processed from the command line. If no objects are specified, the class is determined by the first object encountered within the first archive processed from the command line. If there are no objects or archives, the link-editor creates a 32-bit object. The --6644 option is required to create a 64-bit object solely from a mapfile. This --3322 or --6644 options can also be used in the rare case of linking entirely from an archive that contains a mixture of 32 and 64-bit objects. If the first object in the archive is not the class of the object that is required to be created, then the --3322 or --6644 option can be used to direct the link-editor. See _T_h_e _3_2_-_b_i_t _l_i_n_k_- _e_d_i_t_o_r _a_n_d _6_4_-_b_i_t _l_i_n_k_-_e_d_i_t_o_r in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --aa In static mode only, produces an executable object file. Undefined references are not permitted. This option is the default behavior for static mode. The --aa option can not be used with the --rr option. See SSttaattiicc EExxeeccuuttaabblleess under DESCRIPTION. --bb In dynamic mode only, provides no special processing for dynamic executable relocations that reference symbols in shared objects. Without the --bb option, the link-editor applies techniques within a dynamic executable so that the text segment can remain read-only. One technique is the creation of special position-independent relocations for references to functions that are defined in shared objects. Another technique arranges for data objects that are defined in shared objects to be copied into the memory image of an executable at runtime. The --bb option is intended for specialized dynamic objects and is not recommended for general use. Its use suppresses all specialized processing required to ensure an object's shareability, and can even prevent the relocation of 64-bit executables. --BB ddiirreecctt | nnooddiirreecctt These options govern direct binding. --BB ddiirreecctt establishes direct binding information by recording the relationship between each symbol reference together with the dependency that provides the definition. In addition, direct binding information is established between each symbol reference and an associated definition within the object being created. The runtime linker uses this information to search directly for a symbol in the associated object rather than to carry out a default symbol search. Direct binding information can only be established to dependencies specified with the link-edit. Thus, you should use the --zz ddeeffss option. Objects that wish to interpose on symbols in a direct binding environment should identify themselves as interposers with the --zz iinntteerrppoossee option. The use of --BB ddiirreecctt enables --zz llaazzyyllooaadd for all dependencies. The --BB nnooddiirreecctt option prevents any direct binding to the interfaces offered by the object being created. The object being created can continue to directly bind to external interfaces by specifying the --zz ddiirreecctt option. See Appendix D, _D_i_r_e_c_t _B_i_n_d_i_n_g_s_, in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --BB ddyynnaammiicc | ssttaattiicc Options governing library inclusion. --BB ddyynnaammiicc is valid in dynamic mode only. These options can be specified any number of times on the command line as toggles: if the --BB ssttaattiicc option is given, no shared objects are accepted until --BB ddyynnaammiicc is seen. See the --ll option. --BB eelliimmiinnaattee Causes any global symbols, not assigned to a version definition, to be eliminated from the symbol table. Version definitions can be supplied by means of a mmaappffiillee to indicate the global symbols that should remain visible in the generated object. This option achieves the same symbol elimination as the _a_u_t_o_-_e_l_i_m_i_n_a_t_i_o_n directive that is available as part of a mmaappffiillee version definition. This option can be useful when combining versioned and non-versioned relocatable objects. See also the --BB llooccaall option and the --BB rreedduuccee option. See _D_e_f_i_n_i_n_g _A_d_d_i_t_i_o_n_a_l _S_y_m_b_o_l_s _w_i_t_h _a _m_a_p_f_i_l_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --BB ggrroouupp Establishes a shared object and its dependencies as a group. Objects within the group are bound to other members of the group at runtime. This mode is similar to adding the object to the process by using ddllooppeenn(3C) with the RRTTLLDD__GGRROOUUPP mode. An object that has an explicit dependency on a object identified as a group, becomes a member of the group. As the group must be self contained, use of the --BB ggrroouupp option also asserts the --zz ddeeffss option. --BB llooccaall Causes any global symbols, not assigned to a version definition, to be reduced to local. Version definitions can be supplied by means of a mmaappffiillee to indicate the global symbols that should remain visible in the generated object. This option achieves the same symbol reduction as the _a_u_t_o_-_r_e_d_u_c_t_i_o_n directive that is available as part of a mmaappffiillee version definition. This option can be useful when combining versioned and non-versioned relocatable objects. See also the --BB eelliimmiinnaattee option and the --BB rreedduuccee option. See _D_e_f_i_n_i_n_g _A_d_d_i_t_i_o_n_a_l _S_y_m_b_o_l_s _w_i_t_h _a _m_a_p_f_i_l_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --BB rreedduuccee When generating a relocatable object, causes the reduction of symbolic information defined by any version definitions. Version definitions can be supplied by means of a mmaappffiillee to indicate the global symbols that should remain visible in the generated object. By default, when a relocatable object is generated, version definitions are only recorded in the output image. The actual reduction of symbolic information is carried out when the object is used in the construction of a dynamic executable or shared object. The --BB rreedduuccee option is applied automatically when a dynamic executable or shared object is created. --BB ssyymmbboolliicc In dynamic mode only. When building a shared object, binds references to global symbols to their definitions, if available, within the object. Normally, references to global symbols within shared objects are not bound until runtime, even if definitions are available. This model allows definitions of the same symbol in an executable or other shared object to override the object's own definition. lldd issues warnings for undefined symbols unless --zz ddeeffss overrides. The --BB ssyymmbboolliicc option is intended for specialized dynamic objects and is not recommended for general use. To reduce the runtime relocation processing that is required an object, the creation of a version definition is recommended. --cc _n_a_m_e Records the configuration file _n_a_m_e for use at runtime. Configuration files can be employed to alter default search paths, provide a directory cache, together with providing alternative object dependencies. See ccrrllee(1). --CC Demangles C++ symbol names displayed in diagnostic messages. --dd yy | nn When --dd yy, the default, is specified, lldd uses dynamic linking. When --dd nn is specified, lldd uses static linking. See SSttaattiicc EExxeeccuuttaabblleess under DESCRIPTION, and --BB ddyynnaammiicc|ssttaattiicc. --DD _t_o_k_e_n,... Prints debugging information as specified by each _t_o_k_e_n, to the standard error. The special token hheellpp indicates the full list of tokens available. See _D_e_b_u_g_g_i_n_g _A_i_d_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --ee _e_p_s_y_m ----eennttrryy _e_p_s_y_m Sets the entry point address for the output file to be the symbol _e_p_s_y_m. --ff _n_a_m_e ----aauuxxiilliiaarryy _n_a_m_e Useful only when building a shared object. Specifies that the symbol table of the shared object is used as an auxiliary filter on the symbol table of the shared object specified by _n_a_m_e. Multiple instances of this option are allowed. This option can not be combined with the --FF option. See _G_e_n_e_r_a_t_i_n_g _A_u_x_i_l_i_a_r_y _F_i_l_t_e_r_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --FF _n_a_m_e ----ffiilltteerr _n_a_m_e Useful only when building a shared object. Specifies that the symbol table of the shared object is used as a filter on the symbol table of the shared object specified by _n_a_m_e. Multiple instances of this option are allowed. This option can not be combined with the --ff option. See _G_e_n_e_r_a_t_i_n_g _S_t_a_n_d_a_r_d _F_i_l_t_e_r_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --GG --sshhaarreedd In dynamic mode only, produces a shared object. Undefined symbols are allowed. See Chapter 4, _S_h_a_r_e_d _O_b_j_e_c_t_s_, in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --hh _n_a_m_e ----ssoonnaammee _n_a_m_e In dynamic mode only, when building a shared object, records _n_a_m_e in the object's dynamic section. _n_a_m_e is recorded in any dynamic objects that are linked with this object rather than the object's file system name. Accordingly, _n_a_m_e is used by the runtime linker as the name of the shared object to search for at runtime. See _R_e_c_o_r_d_i_n_g _a _S_h_a_r_e_d _O_b_j_e_c_t _N_a_m_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --ii Ignores LLDD__LLIIBBRRAARRYY__PPAATTHH. This option is useful when an LLDD__LLIIBBRRAARRYY__PPAATTHH setting is in effect to influence the runtime library search, which would interfere with the link-editing being performed. --II _n_a_m_e ----ddyynnaammiicc--lliinnkkeerr _n_a_m_e When building an executable, uses _n_a_m_e as the path name of the interpreter to be written into the program header. The default in static mode is no interpreter. In dynamic mode, the default is the name of the runtime linker, lldd..ssoo..11(1). Either case can be overridden by --II _n_a_m_e. eexxeecc(2) loads this interpreter when the aa..oouutt is loaded, and passes control to the interpreter rather than to the aa..oouutt directly. --ll _x ----lliibbrraarryy _x Searches a library lliibb_x..ssoo or lliibb_x..aa, the conventional names for shared object and archive libraries, respectively. In dynamic mode, unless the --BB ssttaattiicc option is in effect, lldd searches each directory specified in the library search path for a lliibb_x..ssoo or lliibb_x..aa file. The directory search stops at the first directory containing either. lldd chooses the file ending in ..ssoo if --ll_x expands to two files with names of the form lliibb_x..ssoo and lliibb_x..aa. If no lliibb_x..ssoo is found, then lldd accepts lliibb_x..aa. In static mode, or when the --BB ssttaattiicc option is in effect, lldd selects only the file ending in ..aa. lldd searches a library when the library is encountered, so the placement of --ll is significant. See _L_i_n_k_i_n_g _W_i_t_h _A_d_d_i_t_i_o_n_a_l _L_i_b_r_a_r_i_e_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --LL _p_a_t_h ----lliibbrraarryy--ppaatthh _p_a_t_h Adds _p_a_t_h to the library search directories. lldd searches for libraries first in any directories specified by the --LL options and then in the standard directories. This option is useful only if the option precedes the --ll options to which the --LL option applies. See _D_i_r_e_c_t_o_r_i_e_s _S_e_a_r_c_h_e_d _b_y _t_h_e _L_i_n_k_-_E_d_i_t_o_r in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. The environment variable LLDD__LLIIBBRRAARRYY__PPAATTHH can be used to supplement the library search path, however the --LL option is recommended, as the environment variable is also interpreted by the runtime environment. See LLDD__LLIIBBRRAARRYY__PPAATTHH under ENVIRONMENT VARIABLES. --mm Produces a memory map or listing of the input/output sections, together with any non-fatal multiply-defined symbols, on the standard output. --MM _m_a_p_f_i_l_e Reads _m_a_p_f_i_l_e as a text file of directives to lldd. This option can be specified multiple times. If _m_a_p_f_i_l_e is a directory, then all regular files, as defined by ssttaatt(2), within the directory are processed. See Chapter 9, _M_a_p_f_i_l_e _O_p_t_i_o_n_, in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. Example mapfiles are provided in //uussrr//lliibb//lldd. See FILES. --NN _s_t_r_i_n_g This option causes a DDTT__NNEEEEDDEEDD entry to be added to the ..ddyynnaammiicc section of the object being built. The value of the DDTT__NNEEEEDDEEDD string is the _s_t_r_i_n_g that is specified on the command line. This option is position dependent, and the DDTT__NNEEEEDDEEDD ..ddyynnaammiicc entry is relative to the other dynamic dependencies discovered on the link- edit line. This option is useful for specifying dependencies within device driver relocatable objects when combined with the --ddyy and --rr options. --oo _o_u_t_f_i_l_e ----oouuttppuutt _o_u_t_f_i_l_e Produces an output object file that is named _o_u_t_f_i_l_e. The name of the default object file is aa..oouutt. --pp _a_u_d_i_t_l_i_b Identifies an audit library, _a_u_d_i_t_l_i_b. This audit library is used to audit the object being created at runtime. A shared object identified as requiring auditing with the --pp option, has this requirement inherited by any object that specifies the shared object as a dependency. See the --PP option. See _R_u_n_t_i_m_e _L_i_n_k_e_r _A_u_d_i_t_i_n_g _I_n_t_e_r_f_a_c_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --PP _a_u_d_i_t_l_i_b Identifies an audit library, _a_u_d_i_t_l_i_b. This audit library is used to audit the dependencies of the object being created at runtime. Dependency auditing can also be inherited from dependencies that are identified as requiring auditing. See the --pp option, and the --zz gglloobbaallaauuddiitt option. See _R_u_n_t_i_m_e _L_i_n_k_e_r _A_u_d_i_t_i_n_g _I_n_t_e_r_f_a_c_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --QQ yy | nn Under --QQ yy, an iiddeenntt string is added to the ..ccoommmmeenntt section of the output file. This string identifies the version of the lldd used to create the file. This results in multiple lldd iiddeennttss when there have been multiple linking steps, such as when using lldd --rr. This identification is identical with the default action of the cccc command. --QQ nn suppresses version identification. ..ccoommmmeenntt sections can be manipulated by the mmccss(1) utility. --rr ----rreellooccaattaabbllee Combines relocatable object files to produce one relocatable object file. lldd does not complain about unresolved references. This option cannot be used with the --aa option. --RR _p_a_t_h --rrppaatthh _p_a_t_h A colon-separated list of directories used to specify library search directories to the runtime linker. If present and not NULL, the path is recorded in the output object file and passed to the runtime linker. Multiple instances of this option are concatenated together with each _p_a_t_h separated by a colon. See _D_i_r_e_c_t_o_r_i_e_s _S_e_a_r_c_h_e_d _b_y _t_h_e _R_u_n_t_i_m_e _L_i_n_k_e_r in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. The use of a runpath within an associated object is preferable to setting global search paths such as through the LLDD__LLIIBBRRAARRYY__PPAATTHH environment variable. Only the runpaths that are necessary to find the objects dependencies should be recorded. lldddd(1) can also be used to discover unused runpaths in dynamic objects, when used with the --UU option. Various tokens can also be supplied with a runpath that provide a flexible means of identifying system capabilities or an objects location. See Appendix C, _E_s_t_a_b_l_i_s_h_i_n_g _D_e_p_e_n_d_e_n_c_i_e_s _w_i_t_h _D_y_n_a_m_i_c _S_t_r_i_n_g _T_o_k_e_n_s_, in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. The $$OORRIIGGIINN token is especially useful in allowing dynamic objects to be relocated to different locations in the file system. --ss ----ssttrriipp--aallll Strips symbolic information from the output file. Any debugging information, that is, ..lliinnee, ..ddeebbuugg**, and ..ssttaabb** sections, and their associated relocation entries are removed. Except for relocatable files, a symbol table SSHHTT__SSYYMMTTAABB and its associated string table section are not created in the output object file. The elimination of a SSHHTT__SSYYMMTTAABB symbol table can reduce the ..ssttaabb** debugging information that is generated using the compiler drivers --gg option. See the --zz rreeddllooccssyymm and --zz nnoollddyynnssyymm options. --SS _s_u_p_p_o_r_t_l_i_b The shared object _s_u_p_p_o_r_t_l_i_b is loaded with lldd and given information regarding the linking process. Shared objects that are defined by using the --SS option can also be supplied using the SSGGSS__SSUUPPPPOORRTT environment variable. See _L_i_n_k_-_E_d_i_t_o_r _S_u_p_p_o_r_t _I_n_t_e_r_f_a_c_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --tt Turns off the warning for multiply-defined symbols that have different sizes or different alignments. --uu _s_y_m_n_a_m_e ----uunnddeeffiinneedd _s_y_m_n_a_m_e Enters _s_y_m_n_a_m_e as an undefined symbol in the symbol table. This option is useful for loading entirely from an archive library. In this instance, an unresolved reference is needed to force the loading of the first routine. The placement of this option on the command line is significant. This option must be placed before the library that defines the symbol. See _D_e_f_i_n_i_n_g _A_d_d_i_t_i_o_n_a_l _S_y_m_b_o_l_s _w_i_t_h _t_h_e _u _o_p_t_i_o_n in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --VV ----vveerrssiioonn Outputs a message giving information about the version of lldd being used. --YY PP,,_d_i_r_l_i_s_t Changes the default directories used for finding libraries. _d_i_r_l_i_s_t is a colon-separated path list. --zz aabbsseexxeecc Useful only when building a dynamic executable. Specifies that references to external absolute symbols should be resolved immediately instead of being left for resolution at runtime. In very specialized circumstances, this option removes text relocations that can result in excessive swap space demands by an executable. --zz aalllleexxttrraacctt | ddeeffaauulltteexxttrraacctt | wweeaakkeexxttrraacctt ----wwhhoollee--aarrcchhiivvee | ----nnoo--wwhhoollee--aarrcchhiivvee Alters the extraction criteria of objects from any archives that follow. By default, archive members are extracted to satisfy undefined references and to promote tentative definitions with data definitions. Weak symbol references do not trigger extraction. Under the --zz aalllleexxttrraacctt or ----wwhhoollee--aarrcchhiivvee options, all archive members are extracted from the archive. Under --zz wweeaakkeexxttrraacctt, weak references trigger archive extraction. The --zz ddeeffaauulltteexxttrraacctt or ----nnoo--wwhhoollee--aarrcchhiivvee options provide a means of returning to the default following use of the former extract options. See _A_r_c_h_i_v_e _P_r_o_c_e_s_s_i_n_g in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz aalltteexxeecc6644 Execute the 64-bit lldd. The creation of very large 32-bit objects can exhaust the virtual memory that is available to the 32-bit lldd. The --zz aalltteexxeecc6644 option can be used to force the use of the associated 64-bit lldd. The 64-bit lldd provides a larger virtual address space for building 32-bit objects. See _T_h_e _3_2_-_b_i_t _l_i_n_k_- _e_d_i_t_o_r _a_n_d _6_4_-_b_i_t _l_i_n_k_-_e_d_i_t_o_r in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz aassllrr[[==_s_t_a_t_e] Specify whether the executable's address space should be randomized on execution. If _s_t_a_t_e is "enabled" randomization will always occur when this executable is run (regardless of inherited settings). If _s_t_a_t_e is "disabled" randomization will never occur when this executable is run. If _s_t_a_t_e is omitted, ASLR is enabled. An executable that should simply use the settings inherited from its environment should not use this flag at all. --zz ccoommbbrreelloocc | nnooccoommbbrreelloocc By default, lldd combines multiple relocation sections when building executables or shared objects. This section combination differs from relocatable objects, in which relocation sections are maintained in a one-to-one relationship with the sections to which the relocations must be applied. The --zz nnooccoommbbrreelloocc option disables this merging of relocation sections, and preserves the one-to-one relationship found in the original relocatable objects. lldd sorts the entries of data relocation sections by their symbol reference. This sorting reduces runtime symbol lookup. When multiple relocation sections are combined, this sorting produces the least possible relocation overhead when objects are loaded into memory, and speeds the runtime loading of dynamic objects. Historically, the individual relocation sections were carried over to any executable or shared object, and the --zz ccoommbbrreelloocc option was required to enable the relocation section merging previously described. Relocation section merging is now the default. The --zz ccoommbbrreelloocc option is still accepted for the benefit of old build environments, but the option is unnecessary, and has no effect. --zz aasssseerrtt--ddeefflliibb --zz aasssseerrtt--ddeefflliibb==_l_i_b_n_a_m_e Enables warnings that check the location of where libraries passed in with --ll are found. If the link-editor finds a library on its default search path it will emit a warning. This warning can be made fatal in conjunction with the option --zz ffaattaall--wwaarrnniinnggss. Passing _l_i_b_n_a_m_e white lists a library from this check. The library must be the full name of the library, e.g. _l_i_b_c_._s_o. To white list multiple libraries, the --zz aasssseerrtt--ddeefflliibb==_l_i_b_n_a_m_e option can be repeated multiple times. This option is useful when trying to build self-contained objects where a referenced library might exist in the default system library path and in alternate paths specified by --LL, but you only want the alternate paths to be used. --zz ddeeffss | nnooddeeffss ----nnoo--uunnddeeffiinneedd The --zz ddeeffss option and the ----nnoo--uunnddeeffiinneedd option force a fatal error if any undefined symbols remain at the end of the link. This mode is the default when an executable is built. For historic reasons, this mode is nnoott the default when building a shared object. Use of the --zz ddeeffss option is recommended, as this mode assures the object being built is self-contained. A self-contained object has all symbolic references resolved internally, or to the object's immediate dependencies. The --zz nnooddeeffss option allows undefined symbols. For historic reasons, this mode is the default when a shared object is built. When used with executables, the behavior of references to such undefined symbols is unspecified. Use of the --zz nnooddeeffss option is not recommended. --zz ddiirreecctt | nnooddiirreecctt Enables or disables direct binding to any dependencies that follow on the command line. These options allow finer control over direct binding than the global counterpart --BB ddiirreecctt. The --zz ddiirreecctt option also differs from the --BB ddiirreecctt option in the following areas. Direct binding information is not established between a symbol reference and an associated definition within the object being created. Lazy loading is not enabled. --zz eennddffiilltteeee Marks a filtee so that when processed by a filter, the filtee terminates any further filtee searches by the filter. See _R_e_d_u_c_i_n_g _F_i_l_t_e_e _S_e_a_r_c_h_e_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz ffaattaall--wwaarrnniinnggss | nnooffaattaall--wwaarrnniinnggss ----ffaattaall--wwaarrnniinnggss | ----nnoo--ffaattaall--wwaarrnniinnggss Controls the behavior of warnings emitted from the link-editor. Setting --zz ffaattaall--wwaarrnniinnggss promotes warnings emitted by the link- editor to fatal errors that will cause the link-editor to fail before linking. --zz nnooffaattaall--wwaarrnniinnggss instead demotes these warnings such that they will not cause the link-editor to exit prematurely. --zz ffiinniiaarrrraayy==_f_u_n_c_t_i_o_n Appends an entry to the ..ffiinniiaarrrraayy section of the object being built. If no ..ffiinniiaarrrraayy section is present, a section is created. The new entry is initialized to point to _f_u_n_c_t_i_o_n. See _I_n_i_t_i_a_l_i_z_a_t_i_o_n _a_n_d _T_e_r_m_i_n_a_t_i_o_n _S_e_c_t_i_o_n_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz gglloobbaallaauuddiitt This option supplements an audit library definition that has been recorded with the --PP option. This option is only meaningful when building a dynamic executable. Audit libraries that are defined within an object with the --PP option typically allow for the auditing of the immediate dependencies of the object. The --zz gglloobbaallaauuddiitt promotes the auditor to a global auditor, thus allowing the auditing of all dependencies. See _I_n_v_o_k_i_n_g _t_h_e _A_u_d_i_t_i_n_g _I_n_t_e_r_f_a_c_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. An auditor established with the --PP option and the --zz gglloobbaallaauuddiitt option, is equivalent to the auditor being established with the LLDD__AAUUDDIITT environment variable. See lldd..ssoo..11(1). --zz ggrroouuppppeerrmm | nnooggrroouuppppeerrmm Assigns, or deassigns each dependency that follows to a unique group. The assignment of a dependency to a group has the same effect as if the dependency had been built using the --BB ggrroouupp option. --zz gguuiiddaannccee[=_i_d_1,_i_d_2...] Give messages suggesting link-editor features that could improve the resulting dynamic object. Specific classes of suggestion can be silenced by specifying an optional comma separated list of guidance identifiers. The current classes of suggestion provided are: Enable use of direct binding Suggests that --zz ddiirreecctt or --BB ddiirreecctt be present prior to any specified dependency. This allows predictable symbol binding at runtime. Can be disabled with --zz gguuiiddaannccee==nnooddiirreecctt Enable lazy dependency loading Suggests that --zz llaazzyyllooaadd be present prior to any specified dependency. This allows the dynamic object to be loaded more quickly. Can be disabled with --zz gguuiiddaannccee==nnoollaazzyyllooaadd. Shared objects should define all their dependencies. Suggests that --zz ddeeffss be specified on the link-editor command line. Shared objects that explicitly state all their dependencies behave more predictably when used. Can be be disabled with --zz gguuiiddaannccee==nnooddeeffss Version 2 mapfile syntax Suggests that any specified mapfiles use the more readable version 2 syntax. Can be disabled with --zz gguuiiddaannccee==nnoommaappffiillee. Read-only text segment Should any runtime relocations within the text segment exist, suggests that the object be compiled with position independent code (PIC). Keeping large allocatable sections read-only allows them to be shared between processes using a given shared object. Can be disabled with --zz gguuiiddaannccee==nnootteexxtt No unused dependencies Suggests that any dependency not referenced by the resulting dynamic object be removed from the link-editor command line. Can be disabled with --zz gguuiiddaannccee==nnoouunnuusseedd. --zz hheellpp ----hheellpp Print a summary of the command line options on the standard output and exit. --zz iiggnnoorree | rreeccoorrdd Ignores, or records, dynamic dependencies that are not referenced as part of the link-edit. Ignores, or records, unreferenced EELLFF sections from the relocatable objects that are read as part of the link-edit. By default, --zz rreeccoorrdd is in effect. If an EELLFF section is ignored, the section is eliminated from the output file being generated. A section is ignored when three conditions are true. The eliminated section must contribute to an allocatable segment. The eliminated section must provide no global symbols. No other section from any object that contributes to the link-edit, must reference an eliminated section. --zz iinniittaarrrraayy==_f_u_n_c_t_i_o_n Appends an entry to the ..iinniittaarrrraayy section of the object being built. If no ..iinniittaarrrraayy section is present, a section is created. The new entry is initialized to point to _f_u_n_c_t_i_o_n. See _I_n_i_t_i_a_l_i_z_a_t_i_o_n _a_n_d _T_e_r_m_i_n_a_t_i_o_n _S_e_c_t_i_o_n_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz iinniittffiirrsstt Marks the object so that its runtime initialization occurs before the runtime initialization of any other objects brought into the process at the same time. In addition, the object runtime finalization occurs after the runtime finalization of any other objects removed from the process at the same time. This option is only meaningful when building a shared object. --zz iinntteerrppoossee Marks the object as an interposer. At runtime, an object is identified as an explicit interposer if the object has been tagged using the --zz iinntteerrppoossee option. An explicit interposer is also established when an object is loaded using the LLDD__PPRREELLOOAADD environment variable. Implicit interposition can occur because of the load order of objects, however, this implicit interposition is unknown to the runtime linker. Explicit interposition can ensure that interposition takes place regardless of the order in which objects are loaded. Explicit interposition also ensures that the runtime linker searches for symbols in any explicit interposers when direct bindings are in effect. --zz llaazzyyllooaadd | nnoollaazzyyllooaadd Enables or disables the marking of dynamic dependencies to be lazily loaded. Dynamic dependencies which are marked llaazzyyllooaadd are not loaded at initial process start-up. These dependencies are delayed until the first binding to the object is made. NNoottee:: Lazy loading requires the correct declaration of dependencies, together with associated runpaths for each dynamic object used within a process. See _L_a_z_y _L_o_a_d_i_n_g _o_f _D_y_n_a_m_i_c _D_e_p_e_n_d_e_n_c_i_e_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz lldd3322=_a_r_g_1,_a_r_g_2,... --zz lldd6644=_a_r_g_1,_a_r_g_2,... The class of the link-editor is affected by the class of the output file being created and by the capabilities of the underlying operating system. The --zz lldd[3322|6644] options provide a means of defining any link-editor argument. The defined argument is only interpreted, respectively, by the 32-bit class or 64-bit class of the link-editor. For example, support libraries are class specific, so the correct class of support library can be ensured using: lldd ...... --zz lldd3322==--SSaauuddiitt3322..ssoo..11 --zz lldd6644==--SSaauuddiitt6644..ssoo..11 ...... The class of link-editor that is invoked is determined from the EELLFF class of the first relocatable file that is seen on the command line. This determination is carried out pprriioorr to any --zz lldd[3322|6644] processing. --zz llooaaddffllttrr Marks a filter to indicate that filtees must be processed immediately at runtime. Normally, filter processing is delayed until a symbol reference is bound to the filter. The runtime processing of an object that contains this flag mimics that which occurs if the LLDD__LLOOAADDFFLLTTRR environment variable is in effect. See the lldd..ssoo..11(1). --zz mmuullddeeffss ----aallllooww--mmuullttiippllee--ddeeffiinniittiioonn Allows multiple symbol definitions. By default, multiple symbol definitions that occur between relocatable objects result in a fatal error condition. This option, suppresses the error condition, allowing the first symbol definition to be taken. --zz nnooccoommppssttrrttaabb Disables the compression of EELLFF string tables. By default, string compression is applied to SSHHTT__SSTTRRTTAABB sections, and to SSHHTT__PPRROOGGBBIITTSS sections that have their SSHHFF__MMEERRGGEE and SSHHFF__SSTTRRIINNGGSS section flags set. --zz nnooddeeffaauullttlliibb Marks the object so that the runtime default library search path, used after any LLDD__LLIIBBRRAARRYY__PPAATTHH or runpaths, is ignored. This option implies that all dependencies of the object can be satisfied from its runpath. --zz nnooddeelleettee Marks the object as non-deletable at runtime. This mode is similar to adding the object to the process by using ddllooppeenn(3C) with the RRTTLLDD__NNOODDEELLEETTEE mode. --zz nnooddllooppeenn Marks the object as not available to ddllooppeenn(3C), either as the object specified by the ddllooppeenn(()), or as any form of dependency required by the object specified by the ddllooppeenn(()). This option is only meaningful when building a shared object. --zz nnoodduummpp Marks the object as not available to ddlldduummpp(3C). --zz nnoollddyynnssyymm Prevents the inclusion of a ..SSUUNNWW__llddyynnssyymm section in dynamic executables or sharable libraries. The ..SSUUNNWW__llddyynnssyymm section augments the ..ddyynnssyymm section by providing symbols for local functions. Local function symbols allow debuggers to display local function names in stack traces from stripped programs. Similarly, ddllaaddddrr(3C) is able to supply more accurate results. The --zz nnoollddyynnssyymm option also prevents the inclusion of the two symbol sort sections that are related to the ..SSUUNNWW__llddyynnssyymm section. The ..SSUUNNWW__ddyynnssyymmssoorrtt section provides sorted access to regular function and variable symbols. The ..SSUUNNWW__ddyynnttllssssoorrtt section provides sorted access to thread local storage (TTLLSS) variable symbols. The ..SSUUNNWW__llddyynnssyymm, ..SSUUNNWW__ddyynnssyymmssoorrtt, and ..SSUUNNWW__ddyynnttllssssoorrtt sections, which becomes part of the allocable text segment of the resulting file, cannot be removed by ssttrriipp(1). Therefore, the --zz nnoollddyynnssyymm option is the only way to prevent their inclusion. See the --ss and --zz rreeddllooccssyymm options. --zz nnooppaarrttiiaall Partially initialized symbols, that are defined within relocatable object files, are expanded in the output file being generated. --zz nnoovveerrssiioonn Does not record any versioning sections. Any version sections or associated ..ddyynnaammiicc section entries are not generated in the output image. --zz nnooww Marks the object as requiring non-lazy runtime binding. This mode is similar to adding the object to the process by using ddllooppeenn(3C) with the RRTTLLDD__NNOOWW mode. This mode is also similar to having the LLDD__BBIINNDD__NNOOWW environment variable in effect. See lldd..ssoo..11(1). --zz oorriiggiinn Marks the object as requiring immediate $$OORRIIGGIINN processing at runtime. This option is only maintained for historic compatibility, as the runtime analysis of objects to provide for $$OORRIIGGIINN processing is now default. --zz pprreeiinniittaarrrraayy==_f_u_n_c_t_i_o_n Appends an entry to the ..pprreeiinniittaarrrraayy section of the object being built. If no ..pprreeiinniittaarrrraayy section is present, a section is created. The new entry is initialized to point to _f_u_n_c_t_i_o_n. See _I_n_i_t_i_a_l_i_z_a_t_i_o_n _a_n_d _T_e_r_m_i_n_a_t_i_o_n _S_e_c_t_i_o_n_s in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz rreeddllooccssyymm Eliminates all local symbols except for the _S_E_C_T symbols from the symbol table SSHHTT__SSYYMMTTAABB. All relocations that refer to local symbols are updated to refer to the corresponding _S_E_C_T symbol. This option allows specialized objects to greatly reduce their symbol table sizes. Eliminated local symbols can reduce the ..ssttaabb** debugging information that is generated using the compiler drivers --gg option. See the --ss and --zz nnoollddyynnssyymm options. --zz rreellaaxxrreelloocc lldd normally issues a fatal error upon encountering a relocation using a symbol that references an eliminated COMDAT section. If --zz rreellaaxxrreelloocc is enabled, lldd instead redirects such relocations to the equivalent symbol in the COMDAT section that was kept. --zz rreellaaxxrreelloocc is a specialized option, mainly of interest to compiler authors, and is not intended for general use. --zz rreessccaann--nnooww --zz rreessccaann These options rescan the archive files that are provided to the link-edit. By default, archives are processed once as the archives appear on the command line. Archives are traditionally specified at the end of the command line so that their symbol definitions resolve any preceding references. However, specifying archives multiple times to satisfy their own interdependencies can be necessary. --zz rreessccaann--nnooww is a positional option, and is processed by the link- editor immediately when encountered on the command line. All archives seen on the command line up to that point are immediately reprocessed in an attempt to locate additional archive members that resolve symbol references. This archive rescanning is repeated until a pass over the archives occurs in which no new members are extracted. --zz rreessccaann is a position independent option. The link-editor defers the rescan operation until after it has processed the entire command line, and then initiates a final rescan operation over all archives seen on the command line. The --zz rreessccaann operation can interact incorrectly with objects that contain initialization (.init) or finalization (.fini) sections, preventing the code in those sections from running. For this reason, --zz rreessccaann is deprecated, and use of --zz rreessccaann--nnooww is advised. --zz rreessccaann--ssttaarrtt ... --zz rreessccaann--eenndd ----ssttaarrtt--ggrroouupp ... ----eenndd--ggrroouupp --(( ... --)) Defines an archive rescan group. This is a positional construct, and is processed by the link-editor immediately upon encountering the closing delimiter option. Archives found within the group delimiter options are reprocessed as a group in an attempt to locate additional archive members that resolve symbol references. This archive rescanning is repeated until a pass over the archives On the occurs in which no new members are extracted. Archive rescan groups cannot be nested. --zz ttaarrggeett==ssppaarrcc||xx8866 Specifies the machine type for the output object. Supported targets are Sparc and x86. The 32-bit machine type for the specified target is used unless the --6644 option is also present, in which case the corresponding 64-bit machine type is used. By default, the machine type of the object being generated is determined from the first EELLFF object processed from the command line. If no objects are specified, the machine type is determined by the first object encountered within the first archive processed from the command line. If there are no objects or archives, the link-editor assumes the native machine. This option is useful when creating an object directly with lldd whose input is solely from a mmaappffiillee. See the --MM option. It can also be useful in the rare case of linking entirely from an archive that contains objects of different machine types for which the first object is not of the desired machine type. See _T_h_e _3_2_-_b_i_t _l_i_n_k_-_e_d_i_t_o_r _a_n_d _6_4_-_b_i_t _l_i_n_k_-_e_d_i_t_o_r in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz tteexxtt In dynamic mode only, forces a fatal error if any relocations against non-writable, allocatable sections remain. For historic reasons, this mode is not the default when building an executable or shared object. However, its use is recommended to ensure that the text segment of the dynamic object being built is shareable between multiple running processes. A shared text segment incurs the least relocation overhead when loaded into memory. See _P_o_s_i_t_i_o_n_-_I_n_d_e_p_e_n_d_e_n_t _C_o_d_e in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. --zz tteexxttooffff In dynamic mode only, allows relocations against all allocatable sections, including non-writable ones. This mode is the default when building a shared object. --zz tteexxttwwaarrnn In dynamic mode only, lists a warning if any relocations against non-writable, allocatable sections remain. This mode is the default when building an executable. --zz vveerrbboossee This option provides additional warning diagnostics during a link- edit. Presently, this option conveys suspicious use of displacement relocations. This option also conveys the restricted use of static TTLLSS relocations when building shared objects. In future, this option might be enhanced to provide additional diagnostics that are deemed too noisy to be generated by default. --zzwwrraapp==_s_y_m_b_o_l --wwrraapp== _s_y_m_b_o_l ----wwrraapp== _s_y_m_b_o_l Rename undefined references to _s_y_m_b_o_l in order to allow wrapper code to be linked into the output object without having to modify source code. When --zz wwrraapp is specified, all undefined references to _s_y_m_b_o_l are modified to reference ____wwrraapp___s_y_m_b_o_l, and all references to ____rreeaall___s_y_m_b_o_l are modified to reference _s_y_m_b_o_l. The user is expected to provide an object containing the ____wwrraapp___s_y_m_b_o_l function. This wrapper function can call ____rreeaall___s_y_m_b_o_l in order to reference the actual function being wrapped. The following is an example of a wrapper for the mmaalllloocc(3C) function: void * __wrap_malloc(size_t c) { (void) printf("malloc called with %zu\n", c); return (__real_malloc(c)); } If you link other code with this file using --zz wwrraapp==mmaalllloocc to compile all the objects, then all calls to mmaalllloocc will call the function ____wwrraapp__mmaalllloocc instead. The call to ____rreeaall__mmaalllloocc will call the real mmaalllloocc function. The real and wrapped functions should be maintained in separate source files. Otherwise, the compiler or assembler may resolve the call instead of leaving that operation for the link-editor to carry out, and prevent the wrap from occurring. EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS LLDD__AALLTTEEXXEECC An alternative link-editor path name. lldd executes, and passes control to this alternative link-editor. This environment variable provides a generic means of overriding the default link-editor that is called from the various compiler drivers. See the --zz aalltteexxeecc6644 option. LLDD__LLIIBBRRAARRYY__PPAATTHH A list of directories in which to search for the libraries specified using the --ll option. Multiple directories are separated by a colon. In the most general case, this environment variable contains two directory lists separated by a semicolon: _d_i_r_l_i_s_t_1;;_d_i_r_l_i_s_t_2 If lldd is called with any number of occurrences of --LL, as in: lldd ...... --LL_p_a_t_h_1 ... -L_p_a_t_h_n ... then the search path ordering is: _d_i_r_l_i_s_t_1 _p_a_t_h_1 ... _p_a_t_h_n _d_i_r_l_i_s_t_2 LIBPATH When the list of directories does not contain a semicolon, the list is interpreted as _d_i_r_l_i_s_t_2. The LLDD__LLIIBBRRAARRYY__PPAATTHH environment variable also affects the runtime linkers search for dynamic dependencies. This environment variable can be specified with a _32 or _64 suffix. This makes the environment variable specific, respectively, to 32-bit or 64-bit processes and overrides any non-suffixed version of the environment variable that is in effect. LLDD__NNOOEEXXEECC__6644 Suppresses the automatic execution of the 64-bit link-editor. By default, the link-editor executes the 64-bit version when the EELLFF class of the first relocatable file identifies a 64-bit object. The 64-bit image that a 32-bit link-editor can create, has some limitations. However, some link-edits might find the use of the 32-bit link-editor faster. LLDD__OOPPTTIIOONNSS A default set of options to lldd. LLDD__OOPPTTIIOONNSS is interpreted by lldd just as though its value had been placed on the command line, immediately following the name used to invoke lldd, as in: lldd $$LLDD__OOPPTTIIOONNSS ...... _o_t_h_e_r_-_a_r_g_u_m_e_n_t_s ... LLDD__RRUUNN__PPAATTHH An alternative mechanism for specifying a runpath to the link- editor. See the --RR option. If both LLDD__RRUUNN__PPAATTHH and the --RR option are specified, --RR supersedes. SSGGSS__SSUUPPPPOORRTT Provides a colon-separated list of shared objects that are loaded with the link-editor and given information regarding the linking process. This environment variable can be specified with a _32 or _64 suffix. This makes the environment variable specific, respectively, to the 32-bit or 64-bit class of lldd and overrides any non-suffixed version of the environment variable that is in effect. See the --SS option. Notice that environment variable-names that begin with the characters 'LLDD__' are reserved for possible future enhancements to lldd and lldd..ssoo..11(1). FFIILLEESS lliibb_x.so shared object libraries. lliibb_x.a archive libraries. aa..oouutt default output file. _L_I_B_P_A_T_H For 32-bit libraries, the default search path is //uussrr//ccccss//lliibb, followed by //lliibb, and finally //uussrr//lliibb. For 64-bit libraries, the default search path is //lliibb//6644, followed by //uussrr//lliibb//6644. //uussrr//lliibb//lldd A directory containing several mmaappffiilleess that can be used during link-editing. These mmaappffiilleess provide various capabilities, such as defining memory layouts, aligning bss, and defining non-executable stacks. AATTTTRRIIBBUUTTEESS See aattttrriibbuutteess(5) for descriptions of the following attributes: +--------------------+-----------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +--------------------+-----------------+ |Interface Stability | Committed | +--------------------+-----------------+ SSEEEE AALLSSOO aass(1), ccrrllee(1), ggpprrooff(1), lldd..ssoo..11(1), lldddd(1), mmccss(1), ppvvss(1), eexxeecc(2), ssttaatt(2), ddllooppeenn(3C), ddlldduummpp(3C), eellff(3ELF), aarr..hh(3HEAD), aa..oouutt(4), aattttrriibbuutteess(5) _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e NNOOTTEESS Default options applied by lldd are maintained for historic reasons. In today's programming environment, where dynamic objects dominate, alternative defaults would often make more sense. However, historic defaults must be maintained to ensure compatibility with existing program development environments. Historic defaults are called out wherever possible in this manual. For a description of the current recommended options, see Appendix A, _L_i_n_k_-_E_d_i_t_o_r _Q_u_i_c_k _R_e_f_e_r_e_n_c_e_, in _L_i_n_k_e_r _a_n_d _L_i_b_r_a_r_i_e_s _G_u_i_d_e. If the file being created by lldd already exists, the file is unlinked after all input files have been processed. A new file with the specified name is then created. This allows lldd to create a new version of the file, while simultaneously allowing existing processes that are accessing the old file contents to continue running. If the old file has no other links, the disk space of the removed file is freed when the last process referencing the file terminates. The behavior of lldd when the file being created already exists was changed with SSXXCCEE build 4433. In older versions, the existing file was rewritten in place, an approach with the potential to corrupt any running processes that is using the file. This change has an implication for output files that have multiple hard links in the file system. Previously, all links would remain intact, with all links accessing the new file contents. The new lldd behavior bbrreeaakkss such links, with the result that only the specified output file name references the new file. All the other links continue to reference the old file. To ensure consistent behavior, applications that rely on multiple hard links to linker output files should explicitly remove and relink the other file names. September 10, 2013 LD(1)