Mac Osx Set Library Path
On Mac OS X, use otool -L. Solaris has the very useful -s option to ldd that will additionally show the full library search path, so you can confirm that you encoded the right rpath in the binary. A partial equivalent under Linux is. To set DYLDLIBRARYPATH on MAC OS X 10.11 and newer, you must use the following syntax when running an application ('run.app'): DYLDLIBRARYPATH= '/my/path/to/mcr'./run.app This is because dynamic library environment variables are no longer copied to child processes, due to System Integrity Protection. The easy way to find the path would be to open another Finder window and navigate to your home folder on the backup. Drag that home folder to an empty Go to Folder path field and it will fill in the full path, then add /Library on the end. For a new path to be added to PATH environment variable in MacOS just create a new file under /etc/paths.d directory and add write path to be set in the file.
- Mac Osx Set Library Path Command
- Macos Set Ld_library_path
- Mac Osx Set Library Pathology
- Mac Osx Set Library Path Code
- Macos Set Java.library.path
Check your PATH Setting
In the instructions below, $INSTALL_DIR refers to the path to the new install directory, /path/to/dakota/install/directory/Dakota.
Make sure Dakota executables (and optionally test files and current directory) are available on the PATH by typing 'which dakota' at command line prompt. If your PATH variable is set correctly, the path to the dakota binary should be displayed.
If your PATH variable is NOT set correctly, you will get a message like the following:
The following setup will make the dakota command and other helper programs available at the terminal. If you prefer you may refer to the dakota executable using its fully-qualified path. Note, however, that some examples will require modification to work properly if dakota and related helper programs are not on your PATH.
To persist the PATH to Dakota across terminals/sessions, make the following changes to the appropriate shell login script. If you prefer to just test in your current terminal, execute the commands directly in a terminal.
Make Changes in Bash Shell
- Edit your Bash startup file in your favorite text editor. For Linux, this is ~/.bashrc. OS X terminal runs a login shell, and so the start up file may be ~/.bashrc, ~/.bash_profile, ~/.bash_login, or ~/.profile. See the manpage for Bash for more information about the differences between login and non-login shells.
- Modify and export PATH, PYTHONPATH, and (if using a Dakota release prior to 6.8) (DY)LD_LIBRARY_PATH variables. Type the following line, replacing $INSTALL_DIR with the absolute path to your installation directory, e.g. $HOME. You need not add the gui path if you are not using the Dakota GUI, or PYTHONPATH if you do not plan to use the dakota.interfacing Python module.
On Linux:
On OS X:
- Save and close file.
- Update changes in your shell window.
Make Changes in C shell
- Edit the startup file ~/.cshrc in your favorite text editor.
- Modify and export PATH, PYTHONPATH, and (if using a Dakota release prior to 6.8) (DY)LD_LIBRARY_PATH variables. Type the following line, replacing $INSTALL_DIR with the absolute path to your installation directory, e.g. $HOME. You need not add the gui path if you are not using the Dakota GUI, or PYTHONPATH if you do not plan to use the dakota.interfacing Python module.
On Linux:
On OS X:
- Save and close file.
- Update changes in your shell window.
| < Scrum | Russ Allbery > Technical Notes | Small-Scale Puppet > |
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.
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.
Mac Osx Set Library Path Command
That leads to the next approach.
Encoding rpath in applications
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.
-Rworks 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-rpathflag to the linker. One typical way to do this is with-Wl,-rpath,/usr/local/lib.
Macos Set Ld_library_path
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:
Mac Osx Set Library Pathology
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.
Mac Osx Set Library Path Code
| < Scrum | Russ Allbery > Technical Notes | Small-Scale Puppet > |