"Dyld: Library Not Loaded", "Libruby.1.9.1.Dylib" When Calling "Mvim ." in the Command Line

dyld: Library not loaded, libruby.1.9.1.dylib when calling mvim . in the command line

brew will compile MacVim against your currently active ruby which was probably 1.9.3-p125. rvm use 1.9.3-p194 --default && brew uninstall macvim && brew install macvim is probably your best bet to fix your problem.

Library not loaded error -- wrong ruby

this kind of thing could happen when gems are linked wrong, try this:

rvm get head
rvm reinstall 1.9.3-p448
rvm use 1.9.3-p448

This will reinstall the ruby and make all gems pristine, which should prevent such problems from happening - unless gem authors did some extra tricks which go out of standard ruby detection.

Update

Using bundlers flag --deployment or --path is not always safe, the error message says:

/Users/sashafklein/rails/<appname>/vendor/bundle/ruby/1.9.1/gems/posix-spawn-0.3.6/lib/posix_spawn_ext.bundle

Which means the gem was compiled with the other ruby and now can not find it.

The simplest way to fix it is to stop using --deployment flag, as it is persisted the easiest way to get rid of it (and all other potentially dangerous settings) is:

rm -rf .bundle/ vendor/bundle 
bundle install

Interpretation

Bundler does great job filtering gems in runtime, unfortunately it enforces another layer of filtering with the --deployment flag, which forces installation of gems to path that is common for multiple rubies - in this case: ruby/1.9.1, this is unsafe as rubies can be compiled with different settings which can break c-extension gems used in different ruby.

brew installed Vim in Terminal with RVM (Ruby 1.9.3), MacVim and Command-T

I'm guessing that you installed the macvim package before you installed installed all the rest of that, and then installed the vim package afterwards. That'd explain why it works in terminal mode. These are two different packages, and they have their own build options.

Run:

vim --version

And compare the output to:

mvim --version

In particular, check out the last line (starts with Linking:). You'll probably see ruby-1.8 linked in for mvim, and ruby-1.9.1 linked in for vim (note that 1.9.3 reports 1.9.1; it's the C API version, not the Ruby version).

If all this is true, fix it by doing:

brew uninstall macvim
brew install macvim

It should build against your 1.9.3 config. Make sure rvm current reports 1.9.3 before you do that.

Why won't macvim always use ruby 1.9.3?

It took me awhile to find a fix, but the issue is caused by MacVim not loading zsh the same way Terminal loads zsh.

The fix is easy enough and can be placed into your zshrc. See a commit from my dotfiles:

https://github.com/simeonwillbanks/dotfiles/commit/e0e19cfeff13f8bc99d8164217ddd84c6d7f9529

The commit references a full explanation which can be found here:

http://vim.1045645.n5.nabble.com/MacVim-and-PATH-tt3388705.html#a3392363

Hope this helps!

QList and shared_ptr

It seems correct. Boost's shared_ptr is a reference counting pointer. Reference counting is able to reclaim memory if there are no circular references between objects. In your case, objects of class A do not reference any other objects. Thus, you can use shared_ptr without worries. Also, the ownership semantics allow shared_ptrs to be used in STL (and Qt) containers.

---

Related Topics