dyld man page on OpenDarwin

Man page or keyword search:  
man Server   3202 pages
apropos Keyword Search (all sections)
Output format
OpenDarwin logo
[printable version]

DYLD(1)								       DYLD(1)

NAME
       dyld - the dynamic link editor

SYNOPSIS
       DYLD_FRAMEWORK_PATH
       DYLD_FALLBACK_FRAMEWORK_PATH
       DYLD_LIBRARY_PATH
       DYLD_FALLBACK_LIBRARY_PATH
       DYLD_INSERT_LIBRARIES
       DYLD_FORCE_FLAT_NAMESPACE
       DYLD_IMAGE_SUFFIX
       DYLD_PRINT_LIBRARIES
       DYLD_PRINT_LIBRARIES_POST_LAUNCH
       DYLD_EBADEXEC_ONLY
       DYLD_BIND_AT_LAUNCH
       DYLD_DEAD_LOCK_HANG
       DYLD_PREBIND_DEBUG
       DYLD_ABORT_MULTIPLE_INITS
       DYLD_NEW_LOCAL_SHARED_REGIONS
       DYLD_NO_FIX_PREBINDING
       DYLD_TRACE

DESCRIPTION
       The  dynamic  linker  uses  the	following environment variables.  They
       affect any program that uses the dynamic linker.

       DYLD_FRAMEWORK_PATH
	      This is a colon  separated  list	of  directories	 that  contain
	      frameworks.   The	 dynamic  linker  searches  these  directories
	      before it searches for the framework by its  install  name.   It
	      allows  you  to  test  new  versions  of existing frameworks. (A
	      framework is a library  install  name  that  ends	 in  the  form
	      XXX.framework/Versions/YYY/XXX  or  XXX.framework/XXX, where XXX
	      and YYY are any name.)

	      For each framework that a program uses, the dynamic linker looks
	      for  the	framework  in each directory in DYLD_FRAMEWORK_PATH in
	      turn. If it looks in all the  directories	 and  can't  find  the
	      framework,  it  searches the directories in DYLD_LIBRARY_PATH in
	      turn. If it still can't find the	framework,  it	then  searches
	      DYLD_FALLBACK_FRAMEWORK_PATH  and	 DYLD_FALLBACK_LIBRARY_PATH in
	      turn.

	      Use the -L option to otool(1).  to discover the  frameworks  and
	      shared libraries that the executable is linked against.

       DYLD_FALLBACK_FRAMEWORK_PATH
	      This  is	a  colon  separated  list  of directories that contain
	      frameworks.  It is used as the default location  for  frameworks
	      not found in their install path.

	      By    default,	it    is    set	   to	$(HOME)/Library/Frame‐
	      works:/Library/Frameworks:/Network/Library/Frameworks:/Sys‐
	      tem/Library/Frameworks

       DYLD_LIBRARY_PATH
	      This  is	a  colon  separated  list  of directories that contain
	      libraries. The dynamic linker searches these directories	before
	      it  searches  the default locations for libraries. It allows you
	      to test new versions of existing libraries.

	      For each library that a program uses, the dynamic	 linker	 looks
	      for  it  in  each	 directory in DYLD_LIBRARY_PATH in turn. If it
	      still can't  find	 the  library,	it  then  searches  DYLD_FALL‐
	      BACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn.

	      Use  the	-L option to otool(1).	to discover the frameworks and
	      shared libraries that the executable is linked against.

       DYLD_FALLBACK_LIBRARY_PATH
	      This is a colon  separated  list	of  directories	 that  contain
	      libraries.  It is used as the default location for libraries not
	      found  in	 their	install	 path.	 By  default,  it  is  set  to
	      $(HOME)/lib:/usr/local/lib:/lib:/usr/lib.

       DYLD_INSERT_LIBRARIES
	      This  is	a  colon  separated  list of dynamic libraries to load
	      before the ones specified in the program.	 This  lets  you  test
	      new  modules  of existing dynamic shared libraries that are used
	      in flat-namespace images by loading a temporary  dynamic	shared
	      library with just the new modules.  Note that this has no effect
	      on images built a two-level namespace  images  using  a  dynamic
	      shared library unless DYLD_FORCE_FLAT_NAMESPACE is also used.

       DYLD_FORCE_FLAT_NAMESPACE
	      Force  all  images in the program to be linked as flat-namespace
	      images and ignore any two-level namespace	 bindings.   This  may
	      cause programs to fail to execute with a multiply defined symbol
	      error if two-level namespace images are used to allow the images
	      to have multiply defined symbols.

       DYLD_IMAGE_SUFFIX
	      This  is	set  to a string of a suffix to try to be used for all
	      shared libraries used by the program.  For libraries  ending  in
	      ".dylib"	the  suffix  is applied just before the ".dylib".  For
	      all other libraries the suffix is appended to the library	 name.
	      This  is	useful	for using conventional "_profile" and "_debug"
	      libraries and frameworks.

       DYLD_PRINT_LIBRARIES
	      When this is set, the dynamic linker writes to file descriptor 2
	      (normally	 standard  error)  the	filenames of the libraries the
	      program is using.	 This is useful to make sure that the  use  of
	      DYLD_LIBRARY_PATH is getting what you want.

       DYLD_PRINT_LIBRARIES_POST_LAUNCH
	      This  does  the  same  as	 DYLD_PRINT_LIBRARIES but the printing
	      starts after the program gets to its entry point.

       DYLD_EBADEXEC_ONLY
	      When this is set, the dynamic linker does all of the work needed
	      to  launch  a  program without launching it.  This either prints
	      the cause why the program could not be launched or prints a mes‐
	      sage saying the program could be launched.  This variable can be
	      used a supplement to the program ebadexec(1) to determine why  a
	      program  can't  be  launched.  For programs that should not have
	      any undefined symbols when launched the DYLD_BIND_AT_LAUNCH  can
	      also be set to check this.

       DYLD_BIND_AT_LAUNCH
	      When this is set, the dynamic linker binds all undefined symbols
	      the program needs at launch time. This includes function symbols
	      that  can	 are  normally lazily bound at the time of their first
	      call.

       DYLD_DEAD_LOCK_HANG
	      When this is set, the dynamic linker enters a  loop  that	 hangs
	      the  program  if	a  thread  doing  a  dynamic  linker operation
	      attempts to start another dynamic linker operation  before  com‐
	      pleting  the  first.   This  lets	 you  attach a debugger to the
	      process instead of letting the process exit.

       DYLD_PREBIND_DEBUG
	      When this is set, the dynamic linker  prints  diagnostics	 about
	      launching	 prebound programs and libraries. This lets you deter‐
	      mine why a program is not being launched prebound.  You can view
	      the  recorded  library  time  stamps  with  the  -Lv  option  to
	      otool(1).

       DYLD_ABORT_MULTIPLE_INITS
	      When this is set, the dynamic linker causes the program to abort
	      when  multiple  library  initialization  routines	 are being run
	      which can happen if code called  via  a  library	initialization
	      routine  makes  a call to a dyld API. Then under the debugger it
	      is easy to do a back trace and find the code that is making  the
	      call to a dyld API via code called from a library initialization
	      routine

       For secure programs that are UNIX set  uid  or  set  gid,  the  dynamic
       linker  will  not use the dyld environment variables for path searching
       and library insertion, unless the program is run as the real user.  For
       secure  programs,  the  dynamic linker clears out the value of the dyld
       path and insertion environment variables.  This is so that if a program
       is  exec(2)'ed  from  a secure program too will not have it's libraries
       searched for, as well.  For  statically	linked	secure	programs  that
       exec(2)	other  programs	 that  might  use the dynamic linker, they too
       should clear out the values of the dyld path and insertion  environment
       variables.

       DYLD_NEW_LOCAL_SHARED_REGIONS
	      When set, the dynamic linker directs the system to provide a new
	      set of  shared  regions  as  the	repository  for	 library  load
	      requests	for  dynamic libraries built with MH_SPLIT_SEGS (split
	      shared libraries).

	      Split shared libraries reside in a defined contiguous region  of
	      address  space  in  all  dynamic linker runtime processes.  This
	      space is backed by named regions or  sub-maps.   These  sub-maps
	      are  owned by the system and items which are to mapped into them
	      must be mapped via the load_shared_file(2)  call.	  The  use  of
	      sub-maps	promotes  a  high  degree  of  system resource sharing
	      between the processes which incorporate and use them.   However,
	      some  processes require either additional or different libraries
	      to be loaded into the shared region.  While there is some	 space
	      available	 within the shared region for alternate and new shared
	      libraries, it is inappropriate to use that area for temporary or
	      private  libraries.   Setting  the DYLD_NEW_LOCAL_SHARED_REGIONS
	      flag will cause all children of  the  current  process  to  have
	      their  own  set of sub-maps.  In this way the libraries found in
	      the children's submaps will not be caused to be present  in  the
	      submaps shared by the rest of the system.

	      DYLD_NEW_LOCAL_SHARED_REGIONS should be set by anyone wishing to
	      run non-standard or temporary split shared libraries by  setting
	      an   explicit  path  to  point  to  them.	  i.e.	by  using  the
	      DYLD_LIBRARY_PATH environment variable instead of	 changing  the
	      root by executing a chroot(2) call.

       DYLD_TRACE
	      Cause dyld to put tracing information in the kernel trace buffer
	      for its operations.

       DYLD_NO_FIX_PREBINDING
	      Causes dyld not to run  /usr/bin/fix_prebinding  on  executables
	      that  are	 launched  which had prebinding information that could
	      not be used for the launch.

SEE ALSO
       libtool(1), ld(1), otool(1), redo_prebinding(1)

Apple Computer, Inc.		 July 24, 2002			       DYLD(1)
[top]

List of man pages available for OpenDarwin

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]
Tweet
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