dld.so man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

dld.so(5)							     dld.so(5)

       dld.so - dynamic loader

       The dynamic loader is thread-safe.

       The shared library is the 64-bit dynamic loader.	 The shared library is
       the 32-bit dynamic loader.  In programs that use shared	libraries,  is
       invoked	automatically at startup time.	is the 64-bit run-time startup
       file.  is the 32-bit run-time startup file.  The and  shared  libraries
       are  the	 32-bit	 and 64-bit microloaders.  In programs that use shared
       libraries, the microloader is invoked automatically at startup time  by
       exec(2).	  The microloader's sole responsibility is to load the dynamic
       loader, into memory for program execution.  The	microloaders  and  the
       dynamic loaders are, themselves, shared libraries, although they define
       no symbols for use by user programs.

   Shared Libraries
       Shared libraries are executable files created with the option  to  (see
       ld(1)).	 They must contain position-independent code (PIC) that can be
       mapped anywhere in the address space of a  process  and	executed  with
       minimal	relocation.   PIC  can use PC-relative addressing modes and/or
       linkage tables.	The HP compilers generate PIC by default.

   Incomplete Executables
       An executable program linked with  one  or  more	 shared	 libraries  is
       called an

       When  creating  an executable file from object files and libraries, the
       linker does not copy text (code) or data from the shared	 library  into
       the output file.	 Instead, the dynamic loader maps the library into the
       address space of the process at run time.  The linker binds all program
       references  to shared library routines and data to entries in a linkage
       table, and relies on the dynamic loader to fill in  the	linkage	 table
       entries once the libraries have been mapped.  This linkage table serves
       as a jump table for function calls.

   Thread local storage
       Two thread local storage models	are  supported:	 static	 and  dynamic,
       which  is  controlled  by  a  compiler  option  The  default  is Shared
       libraries built with the dynamic model can be loaded  using  dlopen(3C)
       and  shl_load(3X) APIs.	An attempt to load a shared library built with
       the static model using dlopen(3C) or shl_load(3X) APIs will  result  in
       the following error:

       The  dynamic  loader tallies each shared library's thread local storage
       size as well as the program's thread  local  storage  size.   When  all
       libraries  are loaded, the dynamic loader invokes an initializer in the
       system library which does the thread initialization, allocation of  the
       initial thread, and sets the thread pointer.

       An  incomplete  executable  contains a list of path names of the shared
       libraries searched at link time.	  At  run  time,  the  dynamic	loader
       attaches	 to the process all shared libraries that were linked with the
       program.	 The dynamic loader attempts to load  each  library  from  the
       same  directory	in which it was found at link time.  It is possible to
       change the shared library run time search path by specifying a  dynamic
       path list.  (For PA-RISC 32-bit compatibility mode information, see

       The  text  segment  of a library is shared among all processes that use
       it.  The data and bss (uninitialized data) segments  are	 loaded	 on  a
       page-by-page  basis.  When a process first accesses (reads or writes) a
       data or bss page, a copy of that page is made for the process.

   Dynamic Path List
       For default mode	 libraries,  the  dynamic  loader  uses	 dynamic  path
       searching to find shared libraries whose names appear in a library list
       of the program or loaded shared libraries with no  embedded  character.
       Dynamic	path  searching	 is  enabled by default for these libraries or
       executables.  If is specified, the dynamic loader does not look at  any
       dynamic	path environment variables to find dependent shared libraries.
       This limits the dynamic path searching to the value of (run  time  path
       or  embedded  path  set	by  the command) and the default directory for
       64-bit libraries or the default directory for 32-bit libraries.

       For PA-RISC 32-bit compatibility mode  libraries	 (libraries  built  or
       linked  with  the  dynamic  loader only does dynamic path searching for
       these libraries if they were linked with or and one of these were spec‐




       There are several ways to specify a dynamic path list :

       ·  By  storing  a  directory  path list in the executable (in using the
	  option to

       ·  By specifying and letting the linker set the value to	 a  concatena‐
	  tion	of  the followed by the value of the environment variable fol‐
	  lowed by the 64-bit default directory or the 32-bit  default	direc‐

       ·  By storing a directory path list in the environment variables and/or
	  and can contain paths for both 32 and 64 bit libraries; dld.so  will
	  only	load  appropriate  libraries.	For  compatibility mode shared
	  libraries and executables, the directory path list  should  only  be
	  put in the environment variable.

       The  path  list is a list of one or more path names separated by colons
       The dynamic path list works only for libraries specified	 with  the  or
       options	to  However,  it can be enabled for libraries specified with a
       full path name using the option to (see chatr(1)).   If	both  and  are
       used,  their  relative  order  on the command line indicates which path
       list is searched first in compatibility mode.  See the option to	 ld(1)
       or the for more details.

       The dynamic loader uses these rules when determining which dynamic path
       list to use:

       ·  If was specified and and were specified, then the only dynamic  path
	  searching  that  can be done is to look at the path list in followed
	  by the 64-bit default directory or the 32-bit default directory

       ·  If was specified and and were specified, no shared library  is  sub‐
	  ject	to  dynamic  path  searching.	The  link-time location of the
	  library (recorded path) is used.

       ·  If the and options are specified, then the path list in the environ‐
	  ment variable is searched, followed by the path list in the environ‐
	  ment variable, followed by the path list in followed by  the	64-bit
	  default directory or the 32-bit default directory

       ·  If  the  and are specified, then use the relative ordering of and to
	  determine if the dynamic loader should use the path list  in	before
	  followed  by library as specified in the library list.  If is speci‐
	  fied first, use the path list in first.

       The rules change slightly when looking for dependent shared libraries.

       ·  For default mode libraries, provided the executable  is  not	linked
	  with	linker	option,	 the  path list in the environment variable is
	  searched first, followed by the path list in the  environment	 vari‐
	  able,	 followed by the value in the parent shared library's followed
	  by the 64-bit default directory or the 32-bit default directory  The
	  ancestors  of a parent shared library may contain a path list in but
	  this is ignored when searching for  dependent	 shared	 libraries  of
	  this	parent.	  Only	the  parent's  is used.	 setting in executable
	  overrides the setting in dependent shared libraries. That means even
	  if a dependent shared library disables (or enables) it is still hon‐
	  oured (or ignored) if the executable has enabled (or disbaled)

       ·  For compatibility mode libraries, the search is the same as for par‐
	  ent  shared  libraries,  except  can	be  passed  from parent shared
	  libraries to child dependent shared libraries to that child's depen‐
	  dents, and so on.

       The  dynamic  loader also resolves symbolic references between the exe‐
       cutable and libraries.  By default, function calls are trapped via  the
       linkage table and bound on first reference.  References to data symbols
       and other absolute address references  cannot  be  trapped.   They  are
       bound on the first resolution of a function call that could potentially
       reference the object.

       If the option to is used, the loader binds all necessary references  at
       startup	time.	This  increases	 the  startup  cost  of a program, but
       ensures that no more binding operations are required later.  Thus, bet‐
       ter real-time response may result, and the risk of a later abort due to
       unresolved externals is eliminated.

       The tool can be used to improve the start-up time of programs that  use
       shared  libraries (incomplete executables).  The tool performs analysis
       on the shared library routines and data used to bind  the  symbols  and
       stores  this  information  in  the executable file.  The dynamic loader
       notices that this information is available, and it uses	this  fastbind
       information  to bind the symbols instead of the standard search method.
       For more details refer to fastbind(1) and the option to ld(1) or the

   Breadth-first Searching
       By default, the dynamic loader does breadth-first searching when	 bind‐
       ing  symbols.   If the incomplete executable was linked with or if a is
       being executed, then depth-first searching is used.  (See Breadth-first
       searching  specifies that the dynamic loader looks for symbols starting
       with the incomplete executable followed by all loaded shared  libraries
       in  a  left to right order until the symbol is found.  For example, the
       incomplete executable is searched followed  by  all  libraries  in  its
       library	load  list.   Then the dependent shared libraries of the first
       library in the library load list is searched, followed by the dependent
       shared libraries of the second library in the list, and so on.

   Version Control
       Since  code from a shared library is mapped at run time from a separate
       shared library file, modifications to a shared library  may  alter  the
       behavior	 of  existing executables.  In some cases, this may cause pro‐
       grams to operate incorrectly.  Users  can  control  versions  of	 their
       libraries  by  using  a naming convention, where n is a numeral that is
       incremented with every new release of the library.  When using the  new
       naming  scheme,	users  must  specify  an  internal name for the shared
       library by using the option to when building the shared library.	  This
       internal	 name  is  recorded  in	 each  incomplete executable or shared
       library that links with the shared library.

       At run time, the loader looks at	 the  library  list  recorded  in  the
       incomplete  executable file or shared library.  For each library in the
       list that was not an internal name, the dynamic loader looks for a ver‐
       sion  of	 the  library (for example, to load.  If it does not find this
       version, it looks for the library name that is recorded in the list.

   Explicit Loading and Binding
       The duties of the dynamic loader as described above are	all  performed
       automatically,  although they can be controlled somewhat by appropriate
       options to The dynamic loader can also  be  accessed  programmatically.
       The  routines  described	 under shl_load(3X), dlclose(3C), dlerror(3C),
       dlget(3C), dlmodinfo(3C), dlopen(3C), and dlsym(3C) provide a  portable
       interface  that	allows	the  programmer	 to explicitly attach a shared
       library to the process at run time, to calculate the addresses of  sym‐
       bols  defined  within  shared libraries, and to detach the library when

   Global Symbol Table
       The global symbol table mechanism is designed as a performance enhance‐
       ment  option.   Enabling this mechanism causes the creation of a global
       symbol table which speeds up symbol lookup, by eliminating the need  to
       scan  all loaded libraries in order to find a symbol.  This is particu‐
       larly  effective	 for  applications  with  large	 numbers   of	shared
       libraries.  This mechanism is off by default.

       The  global symbol table is implemented using a hash table.  Under this
       mechanism, whenever a library is loaded (either implicitly or by	 using
       or the mechanism hashes the library's exports and places them into this
       table.  When  a	library	 is  unloaded,	the  mechanism	looks  up  the
       library's exports in the table and removes them.

       The  hash  table	 does not contain entries for symbols defined by User-
       defined symbols must therefore be handled separately.

       Enabling the mechanism causes to use more memory and impacts  the  per‐
       formance of the and API calls.

       With  the global symbol table, the dynamic loader may need to perform a
       large number of hashing operations to locate symbols.  Performing  this
       hash  function may cost considerable time, especially when symbol names
       are very long (C++ programs).  To speed up computing hash values can be
       off-loaded to the linker.

       Use the options, and to control the behavior of the global symbol table
       hash mechanism.	See the ld(1) and chatr(1) commands for information on
       these options.

       With these options, you can tune the size to reach a balance of perfor‐
       mance and memory use.  To maximize for performance, tune the table size
       for  an	average	 chain	length of one.	For maximum memory use, at the
       expense of performance, tune the size of the table to minimize the num‐
       ber  of	empty  entries.	  In  general, use prime numbers for the table

       To get statistical information about hash table	performance,  set  the
       environment  variable  to contain the and options.  This combination of
       options provides a message for each library that contains the following

       ·  Operation (load/unload)

       ·  Name of library

       ·  Number of exports

       ·  Number of entries in table with no stored symbols

       ·  Average length of non-zero chains

       ·  Calculated performance of the hash table

       ·  Amount of memory used by the hash table

   Dynamic Loader Behavior in PA-RISC 32-bit Compatibility Mode
       The dynamic loader maintains certain behaviors to support compatibility
       with earlier PA-RISC 32-bit releases.  These operations apply  to  pro‐
       grams  created  with  the  command and the library management routines.
       There are two ways to specify a dynamic path list :

       ·  by storing a directory path list in the executable using the	option

       ·  by linking the executable with option enabling the executable to use
	  the path list defined by the environment variable at run time.

       The path list is a list of one or more path names separated  by	colons
       The  dynamic  path  list works only for libraries specified with the or
       options to However, it can be enabled for libraries  specified  with  a
       full  path  name	 using	the option to (see chatr(1)).  If both and are
       used, their relative order on the command  line	indicates  which  path
       list  is searched first in compatibility mode.  See the option to ld(1)
       or the for more details.	 This is the search behavior used by the  com‐
       patibility mode, and is used if doing a or if the incomplete executable
       was linked with The dynamic loader searches the	incomplete  executable
       followed	 by  the  first	 library  in its library load list.  The first
       dependent library of this library is then  searched,  followed  by  the
       first  dependent	 of this dependent, and so on.	When there are no more
       dependents, the siblings and their dependents are searched until	 even‐
       tually  the  second  library  in	 the  program's	 library  load list is
       searched, followed by the first dependent of this library, and  so  on.
       In  compatibility mode, if you wish to see all of the messages, set the
       environment variable to contain one or  more  options.	The  following
       options are supported:

	      Display  additional  dynamic  loader  warning messages.  Some of

			       · Symbols of the same name but different types,
				 such  as  CODE	 and DATA.  See the section in
				 ld(1) for more details on this warning.

			       · Using certain flags or routines described  in

	      See	       fastbind(1).

	      See	       fastbind(1).

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

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

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

       If  the	dynamic	 loader uses the same load order and symbol resolution
       order as if had been specified as the first library in the link line:

       In a typical command line use (with where is defined as follows:

       The dynamic loader  searches  application  according  to	 but  searches
       according to and/or and/or the embedded path (if enabled).

       NOTE:  Because  the dynamic loader checks the environment variable when
       running any executable (except seteuid/setegid programs), if you export
       you  should  unset  it  after  running your executable, or run the exe‐
       cutable as in the command listed above or in a script.

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

       You can use compiler option to re-compile  the  library	to  avoid  the
       above error message.

       The  load  order	 and symbol resolution order may be different in a PA-
       RISC 32-bit compatibility mode program because the dynamic loader  uses
       depth-first  search  order  in  PA-RISC	32-bit	mode and breadth-first
       search order in standard mode.  See in the option to ld(1) or  the  for
       more information.

       The dynamic loader uses the environment variable even if you use the in
       the link line.  This insures that is enabled even in a link.  The vari‐
       able is always enabled except for setuid and setgid programs.

       NOTE: Using 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 or use

       You can specify multiple libraries as part of the environment variable.
       Separate the libraries by spaces or colons as in (Multi-byte support is
       not  provided  as  part	of parsing the library list).  You can specify
       libraries with absolute paths or relative  paths.   The	libraries  can
       also  consist  of  just	the  library  names, in which case the dynamic
       loader uses the directory path list in the environment variables and/or
       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 However,  if	it  does  not  find  a
       dependent  of  the  libraries, the dynamic loader issues the same error
       message as if the library is specified in the link line.

   The LD_PRELOAD_ONCE Environment Variable
       The feature is similar to except that the dynamic loader, unsets	 after
       reading it, so that any applications invoked by the current application
       do not have set.	 This is useful in situations where the current appli‐
       cation needs certain libraries preloaded while the child application is
       adversely affected if these  are	 preloaded  (for  example,  terminates
       abnormally if contains

       The  libraries specified by are loaded before the ones specified by The
       effect on symbol resolution is that the symbols from  libraries	speci‐
       fied by take precedence over symbols from libraries specified by

   Running Setuid Programs
       For  looking  up	 shared libraries for setuid applications, the dynamic
       loader uses only the paths listed in

       If and are set, they are validated against the list of paths  in	 (This
       allows the individual applications to appropriately order the list from
       the conf file).

       You can turn this feature off by	 setting  the  option  to  Using  this
       option disables setuid programs from all dynamic path lookup.

       The  configuration file is expected to contain a list of shared library
       search paths (delimited by either colon	or  newline  characters).   To
       avoid  redundant	 searches,  you	 should see that one path appears only
       once in the file (and also in the options and The conf file  should  be
       writeable  only by Otherwise, the loader does not use its contents.  If
       does not exist or has the wrong permissions, all dynamic path lookup is
       disabled.   Any	relative  paths	 (paths not starting with slash in the
       path list are ignored by the loader.

       NOTE: Spaces are not allowed in the paths listed.  Everything on a line
       that  follows  a space or character is ignored.	You can use to comment
       out paths in the file.

       If either or is set, and neither contains any path listed in the	 file,
       all dynamic path lookup is disabled.  The paths from the file are not a

       The following is a sample configuration file:

	      # need this for some GNU and shared apps

	      # path below is ignored: path not starting with '/'
	      # and loader will not expand ~ etc.


	      # second path below ignored: space

	      /user/ipfguru/lib/hpux32: user/ipfguru/lib/hpux64
		/net/appserv2/local/lib	 # ignored:line starting with space
	      /opt/java1.3/jre/lib/PA_RISC2.0/	      # java 1.3 PA32
	      /opt/java1.3/jre/lib/PA_RISC2.0/server  # java 1.3 PA32

	      # java 1.4

       If the dynamic loader is not present,  or  cannot  be  invoked  by  the
       process	for  any reason, an error message is printed to standard error
       and the process terminates with a non-zero exit code.

       These errors fall into two basic	 categories:  errors  in  attaching  a
       shared  library,	 and  errors in binding symbols.  The former can occur
       only at process startup time but the latter can occur at any time  dur‐
       ing  process  execution	unless the option is used with Possible errors
       that can occur while attaching a shared	library	 include  library  not
       present,	 library  not executable, library corrupt, high water mark too
       low, or insufficient room in the address space for the library.	Possi‐
       ble  errors  that  can  occur  while binding symbols include symbol not
       found (unresolved external), or library corrupt.

       When using the explicit load facilities of the  dynamic	loader,	 these
       types  of  errors  are  not  considered	fatal.	 Consult shl_load(3X),
       dlclose(3C), dlget(3C), dlgetname(3C), dlmodinfo(3C),  dlopen(3C),  and
       dlsym(3C)  for  more  information.  To see error messages, use the rou‐
       tine.  This routine prints the  last  error  message  recorded  by  the
       dynamic loader.

       The  startup  cost  of  the  dynamic  loader  is significant, even with
       deferred binding, and can cause severe performance degradation in  pro‐
       cesses  dominated by startup costs (such as simple ``hello world'' pro‐
       grams).	In addition, position-independent code is usually slower  than
       normal  code,  so performance of a program may be adversely affected by
       the presence of PIC in shared libraries.	 However,  the	advantages  of
       decreased  disk	space usage and decreased memory requirements for exe‐
       cutables should outweigh these concerns in most cases.

       There are rare cases where the behavior of a program differs when using
       shared libraries as opposed to archive libraries.  This happens primar‐
       ily when relying on undocumented and unsupported features of  the  com‐
       pilers, assembler, and linker.  See the option to ld(1) or the for more

       The library developer is entirely responsible for version  control  and
       must  be thorough in identifying incompatible changes to library inter‐
       faces.  Otherwise, programs may	malfunction  unexpectedly  with	 later
       versions of the library.	 There is little an application user can do if
       version control is not handled properly by the library developer.   The
       application  developer  can  usually  resolve problems by modifying the
       source code to use the new interfaces then  recompiling	and  relinking
       against the new libraries.

       By  default,  most warnings are not reported by the dynamic loader.  If
       you wish to see all error messages, set	the  environment  variable  to

       The and shared libraries were developed by HP.

       list of shared libraries for lookup with setuid programs

   System Tools
       aCC(1)		 invoke the HP-UX aC++ compiler
       as(1)		 translate assembly code to machine code
       cc(1)		 invoke the HP-UX C compiler
       chatr(1)		 change program's internal attributes
       f90(1)		 invoke the HP-UX Fortran 90 compiler
       fastbind(1)	 invoke the fastbind tool
       ld(1)		 invoke the link editor

       a.out(4)		 assembler, compiler, and linker output
       dlclose(3C)	 unload a shared library previously loaded by
       dlerror(3C)	 print the last error message recorded by
       dlget(3C)	 return information about a loaded module
       dlgetname(3C)	 return the name of the storage containing a load mod‐
       dlmodinfo(3C)	 return information about a loaded module
       dlopen(3C)	 load a shared library
       dlsym(3C)	 get the address of a symbol in a shared library
       shl_load(3X)	 load/unload shared libraries

   Texts and Tutorials
       (See the		 option to ld(1))

       (See		 manuals(5) for ordering information)

Itanium(R)-based Systems Only					     dld.so(5)

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net