29 Mar 2012 fallenlord   » (Journeyer)

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"
fi
rvm 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

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!