Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is it OK to use DYLD_LIBRARY_PATH on Mac OS X? And, what's the dynamic library search algorithm with it?

I read some articles discouraging of the use of DYLD_LIBRARY_PATH, as the the path of dynamic library should be fixed using -install_name, @rpath, and @loader_path.

In terms of making a program that runs both on Linux and Mac OS X, DYLD_LIBRARY_PATH of Mac OS X does exactly what LD_LIBRARY_PATH of Linux. And, we can share (almost) the same make file that doesn't have the -install_name and @rpath.

  • Is this OK to use DYLD_LIBRARY_PATH on Mac OS X?
  • What's the dynamic library search algorithm with Mac OS X when the binary can't find the dynamic library? current directory -> DYLD_LIBRARY_PATH directories ... ?
like image 594
prosseek Avatar asked Jun 30 '10 03:06

prosseek


People also ask

What is Dyld_library_path?

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.

What is Dylib Mac OS X?

A file with the DYLIB file extension is a Mach-O (Mach Object) Dynamic Library file that an application references during runtime in order to perform certain functions on an as-needed basis. The format has replaced the older A. OUT file format.

What is Dyld_fallback_library_path?

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.

What is Rpath OSX?

@rpath stands for Runpath Search Path. In the Xcode, it's set with LD_RUNPATH_SEARCH_PATH setting. In ld command tool it's set with -rpath parameter when linking. So it's a search path for the linker. Runtime Search Path instructs the dynamic linker to search a list of paths in order, to locate the dynamic library.


1 Answers

As you've noted, DYLD_LIBRARY_PATH behaves like LD_LIBRARY_PATH on other *nix. However, there is another environment variable you should look at called DYLD_FALLBACK_LIBRARY_PATH.

In general, these are (both on osx and linux) suggested only for development use as they can cause symbol lookup errors when you override with a library that does not have the same symbol table. A good example of this is when you attempt to override the default install of VecLib (e.g. blas lapack) with a custom install. This will cause symbol not found errors in applications linked to the system VecLib if DYLD_LIBRARY_PATH is set and the reverse (symbol lookup errors in custom applications) if it is not. This is due to the system blas/lapack not being a full implementation of the ATLAS libs.

DYLD_FALLBACK_LIBRARY_PATH will not produce these problems.

When installing libraries to a non-standard location, DYLD_FALLBACK_LIBRARY_PATH is much more sane. This will look for symbols in libraries provided in the default paths and if the symbol is not found there, fall back to the specified path.

The benefit is that this process will not cause symbol lookup errors in applications compiled against the default libraries.

In general, when libraries are installed to non-standard locations absolute paths should be specified which negates the ambiguity of the dynamic lookup.

like image 54
jkyle Avatar answered Sep 22 '22 13:09

jkyle