HP-UX Reference (11i v3 07/02) - 1 User Commands A-M (vol 1)

l
ld_ia(1)
Integrity Systems Only
ld_ia(1)
• Archive or shared libraries are added/removed to/from the linker command line.
• Object files are removed from the linker command line.
Use the +help option or see the Linker and Libraries User’s Guide for more information.
Archive Library Processing
The incremental linker searches an archive library if there are unsatisfied symbols. It extracts all archive
members satisfying unsatisfied symbols and processes them as new object files. If an archive library is
modified, the linker replaces the modified archive library.
An object file extracted from an archive library in the previous link remains in the output load module even
if all references to symbols defined in the object file have been removed. The linker removes these object
files when it performs the next initial incremental link.
Shared Library Processing
In an initial incremental link, the linker scans shared library symbol tables and resolves unsatisfied sym-
bols the same way it would in a regular link. In incremental links, the linker does not process shared
libraries and their symbol tables at all and does not report shared library unsatisfied symbols. The detec-
tion of unsatisfied symbols is left to the The dynamic loader. If any of the shared libraries on the command
line was modified, the linker reverts to an initial incremental link.
Performance
Performance of the incremental linker may suffer greatly if you change a high percentage of object files.
The incremental linker may not link small programs much faster, and the relative increase in size of the
executable is greater than that for larger programs.
Do not use the incremental linker to create final production modules. Because it reserves additional pad-
ding space, modules created by the incremental linker are considerably larger than those created in regular
links.
Security Restrictions
On a system that supports fine-grained privileges, if a process gains any privileges from the binary’s
extended attributes, dynamic path lookup is disabled. Similarly, on a system that supports compartments,
if a process changes compartment due to the binary’s extended attributes, the dynamic path lookup is dis-
abled. See setfilexsec(1M) on how to set extended attributes on a binary. See privileges(5) and compart-
ments(5) for more information on privileges and compartments.
Linking Secure Programs
Secure programs are programs that are commonly run by privileged users, such as
root, or programs that
run with elevated privileges due to
setuid or setgid protection. Yous should take Special precautions
when linking secure programs that use shared libraries. The default linker behavior may be sufficient for
secure PA-RISC 32-bit applications, but not for PA-RISC 64-bit or Integrity system applications.
Secure programs should be linked with the option +noenvvar to disable the use of SHLIB_PATH and
LD_LIBRARY_PATH for locating shared library dependencies. Secure programs should also link with
+nodefaultrpath to prevent the automatic construction of an embedded search path based on search
directories specified with
-L options. Most directories searched at link time don’t need to be searched at
run time, and if these directories are specified as relative paths, they expose the program to the same secu-
rity risks as the use of SHLIB_PATH and LD_LIBRARY_PATH.
Programs built with +compat are linked as if +noenvvar and +nodefaultrpath were specified.
However, additional PA-RISC 32-bit compatibility features are also enabled by +compat.
Normal programs that depend on libraries that only exist in a directory specified in
SHLIB_PATH or
LD_LIBRARY_PATH must not be linked with +noenvvar , and if +compat is used, +s must also be
used to enable searching
SHLIB_PATH and LD_LIBRARY_PATH. Programs that depend on
SHLIB_PATH or LD_LIBRARY_PATH cannot be protected as setuid or setgid programs.
dld uses the dynamic path lookup (with SHLIB_PATH and LD_LIBRARY_PATH) only if the following
conditions are satisfied:
getuid() == geteuid() && getgid() == getegid()
That is, if the uid or gid does not match its effective counterpart, dld does not check the directories
specified in SHLIB_PATH and LD_LIBRARY_PATH, which causes the runtime error "library not
found
".
HP-UX 11i Version 3: February 2007 − 16 − Hewlett-Packard Company 533