Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
LD.ELF_SO(1)		  BSD General Commands Manual		  LD.ELF_SO(1)

     ld.elf_so -- run-time link-editor (linker)

     ld.elf_so is a self-contained, position independent program image provid-
     ing run-time support for loading and link-editing shared objects into a
     process' address space.  It uses information stored in data structures
     within the	binary (see elf(5)) and	environment variables to determine
     which shared objects are needed.  These shared objects are	loaded at a
     convenient	virtual	address	using the mmap(2) system call.	After all
     shared objects have been successfully loaded, ld.elf_so proceeds to re-
     solve external references from both the main program and all objects
     loaded.  Once all required	references are resolved	control	is passed to
     the program via its entry point.

     On	the execution of a dynamically linked binary the kernel	will load the
     program and its run-time linker as	specified in the PT_INTERP section in
     the program header.  At this point, instead of passing control directly
     to	the program, the kernel	passes control to the specified	linker.	 An
     auxiliary vector of information is	passed that includes the address of
     the program header, the size of each entry	in the header, and the number
     of	entries.  The entry point of the program and the base address of where
     ld.elf_so is loaded is also supplied.

   Finding objects
     Each elf(5) object	file may contain information in	its dynamic (PT_DY-
     NAMIC) section about which	shared objects it requires (often referred to
     as	dependencies).	These dependencies are specified in the	optional
     DT_NEEDED entry within the	dynamic	section.  Each DT_NEEDED entry refers
     to	a filename string of the shared	object that is to be searched for.

     The linker	will search for	libraries in three lists of paths:

     1.	  A user defined list of paths as specified in LD_LIBRARY_PATH and

	  The use of	should be avoided as the setting of a global
	  search path can present a security risk.

     2.	  A list of paths specified within a shared object using a DT_RPATH
	  entry	in the dynamic section.	 This is defined at shared object link

     3.	  The list of default paths which is set to /usr/lib.

     ld.elf_so will expand the following variables if present in the paths:

     $HWCAP	Processor hardware capabilities, for example FPU, MMX, SSE.
		Currently unimplemented.

     $ISALIST	List of	instructions sets this processor can execute.  Cur-
		rently unimplemented.

     $ORIGIN	The directory of the main object.  Implemented in ld.elf_so
		but the	kernel support is currently disabled.

     $OSNAME	The value of the kern.ostype sysctl(3).

     $OSREL	The value of the kern.osrelease	sysctl(3).

     $PLATFORM	The value of the hw.machine_arch sysctl(3).

     Both ${VARIABLE} and $VARIABLE are	recognized.

     The filename string can be	considered free	form, however, it will almost
     always take the form lib<name>.so.<number>, where name specifies the
     `library' name and	number is conceptually the library's major version

     This name and another of the form lib<name>.so are	normally symbolic
     links to the real shared object which has a filename of the form
     lib<name>.so.<major>.<minor>[.<teeny>].  This naming convention allows a
     versioning	scheme similar to a.out(5).

     ld.elf_so will perform all	necessary relocations immediately except for
     relocations relating to the Procedure Linkage Table (PLT).	 The PLT is
     used as a indirection method for procedure	calls to globally defined
     functions.	 It allows, through the	use of intermediate code, the delayed
     binding of	a call to a globally defined function to be performed at pro-
     cedure call time.	This `lazy' method is the default (see LD_BIND_NOW).

     A mechanism is provided for initialization	and termination	routines to be
     called, on	a per-object basis before execution of the program proper be-
     gins or after the program has completed.  This gives a shared object an
     opportunity to perform any	extra set-up or	completion work.

     The DT_INIT and DT_FINI entries in	the dynamic section specify the	ad-
     dresses of	the initialization and termination functions, respectively,
     for the shared object.  ld.elf_so arranges	for each initialization	func-
     tion to be	called before control is passed	to the program and for the
     termination functions to be called	by using atexit(3).

     This mechanism is exploited by the	system-supplied	constructor initial-
     ization and destructor code located in /usr/lib/crtbeginS.o and
     /usr/lib/crtendS.o.  These	files are automatically	included by cc(1) and
     c++(1) in the list	of object-code files passed to ld(1) when building a
     shared C or C++ object.

     If	the following environment variables exist they will be used by

     LD_LIBRARY_PATH  A	colon separated	list of	directories, overriding	the
		      default search path for shared libraries.

     LD_PRELOAD	      A	colon or space separated list of shared	object file-
		      names to be loaded after the main	program	but before its
		      shared object dependencies.  Space is allowed as a sepa-
		      rator for	backwards compatibility	only.  Support may be
		      removed in a future release and should not be relied

     LD_BIND_NOW      If defined immediate binding of Procedure	Link Table
		      (PLT) entries is performed instead of the	default	lazy

     LD_DEBUG	      If defined a variety of debug information	will be	writ-
		      ten to the standard error	of an dynamically linked exe-
		      cuted when it is run.  This variable is only recognized
		      if ld.elf_so was compiled	with debugging support

     /etc/  library location hints supplied by the system adminis-

     ld(1), ld.aout_so(1), dlfcn(3), elf(5)

     The ELF shared library model employed first appeared in Sys V R4.

     The path expansion	variables first	appeared in Solaris 10,	and in
     NetBSD 5.0.

     The environment variables LD_LIBRARY_PATH and LD_PRELOAD are not honored
     when executing in a set-user-ID or	set-group-ID environment.  This	action
     is	taken to prevent malicious substitution	of shared object dependencies
     or	interposition of symbols.

BSD			       December	17, 2010			   BSD


Want to link to this manual page? Use this URL:

home | help