Most of the utilities depend on the path variable. However, if what you're looking for is in your path chances are you don't really need to know where it is unless there are multiple copies of the same executable. This doesn't apply to most things running in OSX though because they aren't run quite like normal linux/unix binaries.
July 24th, 2015For each library that a program uses, the dynamic linker looks for it in each directory in DYLDLIBRARYPATH in turn. If it still can't find the library, it then searches DYLDFALLBACKFRAMEWORKPATH and DYLDFALLBACKLIBRARYPATH in turn. 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. Restart the terminal. Restart the terminal.
I doubt you need to do anything with DYLDLIBRARYPATH. What you need to do is set ORACLEHOME to the path to your Oracle directory. On Linux, this is something like /pkg/oracle/10.2.0. I'm sure it will be different on your machine. You will have to set that up in your.bashprofile so it gets set before running any scripts that depend on Oracle. 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.
A recent (and even more recently reverted) change to Homebrew highlighted an interesting (read: maddening) quirk of clang on OS X. Here’s the background.
When you compile something using clang on OS X there are (roughly speaking) two stages to the compile. In the first, your source code is loaded and the compiler searches its include paths to find your includes. Here’s what clang’s defaults look like for the Xcode 6.4 command line tools:
As you can see, the include search starts with /usr/local/include and /usr/include is the fourth item. So, in the case of a vanilla OS X install a binary attempting to compile using OpenSSL (let’s say #include <openssl/x509.h>) would find the OpenSSL headers in /usr/include after searching the previous 3 locations fruitlessly.
Once it’s found (and the C preprocessor has run and all the objects have been compiled) we now need to link it. When compiling something against OpenSSL you’ll link against -lssl, -lcrypto, or both. These command line flags simply tell the linker to look for something named “libssl.dylib” or “libcrypto.dylib” in the library search paths. But what are those paths?
This time we see two primary library search paths, /usr/lib and /usr/local/lib…which are reversed in priority from our include search path.
The result of this is that if you have something (like OpenSSL) that is present in both /usr/local/{include,lib} and /usr/{include,lib} you’ll end up with the compiler using the headers from /usr/local/include and then linking against the library in /usr/lib. This can result in a variety of problems, the severity of which depend on how different the two versions of the library are and what features the binary you’re compiling is using.
So why does this matter? Well, in El Capitan (10.11) Apple has chosen to remove the OpenSSL development headers, but not remove the dylibs. They deprecated use of system OpenSSL in Lion (10.7) so this makes sense on the surface, but the weird include/linker ordering means that if homebrew (or anything else living in your include/search paths) duplicates a system library bad things may occur. There are four possible paths (all of which are under the control of Apple and not us plebes):
- Change the linker order preference. Probably a good idea long term but likely to cause all sorts of unintended breakage as we find things that are implicitly depending on this crazy ordering.
- Re-add the OpenSSL headers for 0.9.8. Not a great option since 0.9.8 is scheduled for EOL at the end of this year and Apple has marked it deprecated in OS X since Lion (originally released July 20, 2011), but probably the safest and lowest friction option.
- Remove OpenSSL entirely. This would break any OS X app that links against it and would require Apple to ship updates to Ruby, Python, Apache, etc that statically link OpenSSL (or go down the route of a “private” dylib like they’ve done with OpenSSH in El Capitan)
- Do nothing and let this be a significant source of pain for developers during El Capitan’s lifecycle. This is the most likely scenario.
I favor either removing the OpenSSL dylibs entirely for El Capitan or re-adding the OpenSSL headers and then removing everything in the next major release, but I don’t envy whoever has to make this choice. Everything has downsides.
Application users often need to organize their applications within their file systems in a way that makes them more efficient to use. This capability is easy to provide for a single binary because the location of its dependent libraries is easy to determine: They may reside at a standard location in the file system or at a location relative to the binary itself. However, when dealing with a set of applications that share dependent libraries (for example, in an application suite), providing users the ability to relocate the suite directory is more difficult: Either the suite’s dependent libraries must be located outside the suite directory, or each of the suite’s executables must be linked taking into account its position within the suite. In OS X v10.5 and later the linker and dynamic loader offer a simple way of allowing multiple executables in an application suite directory to share dependent libraries while providing the suite’s users the option of relocating the suite directory. Using run-path dependent libraries you can create a directory structure containing executables and dependent libraries that users can relocate without breaking it.
A run-path dependent library is a dependent library whose complete install name is not known when the library is created (see How Dynamic Libraries Are Used). Instead, the library specifies that the dynamic loader must resolve the library’s install name when it loads the executable that depends on the library.
To use run-path dependent libraries, an executable provides a list of run-path search paths, which the dynamic loader traverses at load time to find the libraries.
Macos Set Java.library.path
This article describes how to create run-path dependent libraries and how to use them in executables.
Creating Run-Path Dependent Libraries
To create a run-path dependent library, you specify a run-path–relative pathname as the library’s install name. A run-path-relative pathname uses the @rpath macro to specify a path relative to a directory to be determined at runtime. A run-path–relative pathname uses the following format:
Mac Osx Set Library Pathology
These are examples of run-path–relative pathnames:
@rpath/libMyLib.dylib@rpath/MyFramework.framework/Versions/A/MyFramework
Mac Os Set Dyld_library_path
A run-path install name is an install name that uses a run-path–relative pathname. You specify a run-path install name while creating the dependent library using the gcc -install_name option. See the gcc man page for more information.
Using Run-Path Dependent Libraries
To use run-path dependent libraries (those using run-path install names) on an executable, you specify one or more run-path search paths with the ld -rpath option (each -rpath clause specifies one run-path location). When the dynamic loader (dyld) loads the executable, it looks for run-path dependent libraries in the run-path search paths in the order in which they were specified at link time.
This is an example of a list of run-path search paths:
Note: Run-path dependent libraries can also be used as regular dependent libraries by specifying absolute pathnames instead of run-path–relative pathnames in -rpath clauses and ensuring that the libraries reside at the specified locations.
Mac Osx Set Library Path Data
Copyright © 2012 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2012-07-23