RVM and OSX's dynamic library loader
The usual way that users of RVM would fix dynamic library loading issues like this:
/Users/pfalcone/.rvm/gems/ruby-1.9.3-p125/gems/mysql2-0.3.11/lib/mysql2.rb:9:in `require': dlopen(/Users/pfalcone/.rvm/gems/ruby-1.9.3-p125/gems/mysql2-0.3.11/lib/mysql2/mysql2.bundle, 9): Library not loaded: libmysqlclient.18.dylib (LoadError)
is to fire up the install_name_tool
utility to manually point the linker to use a specific version of the dynamic library to be loaded:sudo install_name_tool -change libmysqlclient.18.dylib /usr/local/mysql/lib/libmysqlclient.18.dylib /Users/pfalcone/.rvm/gems/ruby-1.9.3-p125/gems/mysql2-0.3.11/lib/mysql2/mysql2.bundle
Doing this, however, becomes tedious over time, whenever one upgrades the Ruby versions, or use different gemsets for different projects. Also, the loader will fail if that specific version of the library gets upgraded (for example, libmysqlclient.18.dylib gets upgraded to libmysqlclient.20.dylib), necessitating the reuse of the install_name_tool utility all over again.
One solution to avoid doing this over and over again is to use the DYLD_FALLBACK_LIBRARY_PATH environment in Mac OSX inside the .rvmrc file:
if [ `uname` == 'Darwin' ]then export DYLD_FALLBACK_LIBRARY_PATH="/usr/local/mysql/lib:$DYLD_FALLBACK_LIBRARY_PATH"firvm use ruby-1.9.3-p125
Unlike the use of DYLD_LIBRARY_PATH or the traditional LD_LIBRARY_PATH as found in most Unix implementations, DYLD_FALLBACK_LIBRARY_PATH does not override the default paths used by the dynamic loader to look for shared objects: instead, the loader attempts to find first the libraries it needs in the standard locations first (like /usr/lib and /usr/local/lib) before it attempts to check the fallback paths.
Syndicated 2012-03-29 04:31:00 (Updated 2012-03-29 04:31:45) from Paolo Alexis Falcone