Since Mac uses bash shell, so the environment variables can be added to the.bashprofile directory, for the current user. The path to this file can be found using the command The path to this. Mac OS X System & Mac Software Shared library search path. Thread starter rkubrick. Does not have an absolute path set. I have to set the DYLDFALLBACKLIBRARYPATH to /opt/local/lib to let dyld find it at runtime. What makes the other libraries installed under /opt/local/lib (QuantLib, boost) have their path recorded in the executable?

1. Mac Osx Set Library Pathology
2. Mac Osx Set Library Path
3. Macos Set Ld_library_path

It's becoming more and more common these days to link everything againstshared libraries, and in fact many software packages (Tcl and Cyrus SASLcome to mind) basically just don't work properly static. This means thatone has to more frequently deal with the issues involved in finding theappropriate libraries at runtime.

Here's a brief primer on the way that this works on Solaris and Linux.The search paths for libraries come from three sources: the environmentvariable LD_LIBRARY_PATH (if set), any rpath encoded in the binary (moreon this later), and the system default search paths. They're searched inthis order, and the first matching library found is used.

LD_LIBRARY_PATH is broken and should not be used if at all possible. It'sbroken because it overrides the search paths for all binaries that you runusing it, not just the one that you care about, and it doesn't add easilyto other competing settings of LD_LIBRARY_PATH. It has a tendency tocause odd breakage, and it's best to only use it with commercialapplications like Oracle where there's no other choice (and then to set itonly in a wrapper around a particular application, and never in yourgeneral shell environment).

Now, more about the other two mechanisms in detail.

Mac Osx Set Library Pathology

System default paths

Far and away the best way of handling shared libraries is to add everydirectory into which you install shared libraries to the system defaultpaths. This doesn't work if you install a variety of conflictinglibraries, but that's a rare case. If you're just installing softwareinto /usr/local/lib, for example, then just add /usr/local/lib to yoursystem default search paths.

On Linux, you do this by adding those directories to /etc/ld.so.conf andthen running ldconfig. On Solaris, you do this by using the crlecommand (see the man page for more details).

This doesn't always work, though. The main case where this doesn't workis when you're installing shared libraries into a shared network filesystem for use throughout your cluster or enterprise. Then, you probablydon't want to add that network file system to the default system searchpath, since that search path is used for every binary on the system,including ones integral to the operation of the system. If the networkfile system goes down, and the default search path includes it, the systemwill become unusable.

That leads to the next approach.

Encoding rpath in applications

Mac Osx Set Library Path

ELF binaries (used by Solaris and Linux) can contain in the binarysupplemental paths for shared libraries. (Shared libraries can alsocontain their own supplemental paths for finding other shared libraries,but that's not as commonly used.) This path is searched before the systemdefault paths (but is overridden by LD_LIBRARY_PATH, if set).

This path must be encoded at compile time and after that doesn't change.The advantage of this approach over the LD_LIBRARY_PATH approach, apartfrom the other problems caused by LD_LIBRARY_PATH, is that the work isborn by the person building the software rather than the person runningit. That means the work of configuring library paths only has to be doneonce, by a fairly clued person, rather than by every user who may or maynot understand the issues.

There are two basic ways of telling a compiler to encode a search path inthe binary (called an rpath):

• Set the environment variable LD_RUN_PATH to the search path (colon-separated) you want to encode. You don't need to include the system default search directories (and indeed should not, since you may interfere with future changes in how the native library searching algorithm works). This environment variable will be picked up by the compiler when it links the binary.

• Add a linker flag such as -R /usr/local/lib (or whatever path) to the link command line. You can repeat this flag multiple times with different paths, similar to -L. Its order in the command line doesn't matter.

  Different compiler and linker combinations require different flags. -R works for many GNU compiler and linker combinations, but not all compilers and linkers. In some cases, you may have to instead tell the compiler to pass the -rpath flag to the linker. One typical way to do this is with -Wl,-rpath,/usr/local/lib.

Either can be used, so normally I use LD_RUN_PATH since it's lessintrusive. However, note that if there are any -R or-Wl,-rpath flags on the command line, the LD_RUN_PATH setting willtypically be ignored. This means that, if the normal build process of thesoftware adds -R flags, you'll need to get it to add your -Rflags as well (unless it helpfully includes a -R flag for theinstallation directory, which it sometimes does). If the software packageuses Autoconf, generally the easiest way to do this is to set LDFLAGS to'-R /usr/local/lib' (or whatever directory) before runningconfigure, which will then stick it into the Makefile. Failing that, I'llsometimes do something like:

to build the software, which generally does the right thing. (The sameapplies to -Wl,-rpath flags if you need to use it instead.

Note that software that uses libtool to link its libraries and to linkagainst libraries will more frequently do the right thing and encode rpathproperly when it builds the final binaries, but not always. Thankfullylibtool also understands the -R and -Wl,-rpath flags anddoes the right thing when it's provided.

Checking the binaries

To verify that a binary is doing the right thing, use the commandldd on the binary. This will list all of the libraries and eitherwhere they came from (if found) or something like '(not found)' if thelibrary wasn't found. On Mac OS X, use otool -L.

Solaris has the very useful -s option to ldd that willadditionally show the full library search path, so you can confirm thatyou encoded the right rpath in the binary.

A partial equivalent under Linux is:

but note that this only shows the rpath for a particular binary(executable or library). If a shared library depends on other sharedlibraries, those shared libraries may be searched for using the rpath ofthe shared library that is loading them. To make sure that the searchpath is correct on Linux, you may need to use the above readelf command onthe binary and all libraries other than system libraries that it uses.readelf comes with binutils, so if you're compiling software you willprobably already have it installed.

Changing the rpath

On Linux, a utility called patchelfis available that can modify or remove the rpath or add one if one was notalready present. This utility replaces the older chrpath utility, whichappears to no longer be maintained.

patchelf won't compile on Solaris out of the box. For it, you may stillneed chrpath. The maintainer's FTP site used to be atftp://ftp.hungry.com/pub/hungry/chrpath/ but has been unreachable for sometime. At this point, the best source is probably theDebian package.

Mac OS X comes with a utility named install_name_tool that can makesimilar modifications to the rpath encoded in a binary. However, it can'tchange the rpath to one that's longer than the original unless the binarywas built with the linker flag -headerpad_max_install_names.

Other platforms

I'm afraid I don't have as much helpful information about Tru64, HP-UX,AIX, or IRIX. HP-UX and AIX don't use ELF, and therefore have acompletely different linking mechanism. Tru64 and IRIX seem to oftenencode library locations at build time based on where the library wasfound and therefore don't need either of these mechanisms, but I don'tknow exactly how that works. HP-UX and AIX may do something similar.

Note that another option is to just build your software against the staticlibraries. This is what we used to do at Stanford on all platforms otherthan Solaris and Linux (and the BSDs, although I don't normally build onBSD systems), since the handling of shared library versioning anddependencies is considerably less robust on other systems.

Macos Set Ld_library_path