You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Bug #1524: Linker errors with MacVim and Ruby 1.9.1 ("dlyd: Symbol not found: _rb_intern2")

Kind bug
Product Command-T
When Created , updated
Status closed
Reporter anonymous
Tags no tags

Description

Hi,

Me again :)

I've compiled it again on my mac (Snow Leo; MacVim compiled from source with ruby support; Ruby 1.9.1; hash check commented out in ext.c), but I get this error when I want to launch vim: 

[ktamas@espell-mac:~/Prog]$ vim helloworld.rb
dyld: lazy symbol binding failed: Symbol not found: _rb_intern2
  Referenced from: /Users/ktamas/.vim/ruby/command-t/ext.bundle
  Expected in: flat namespace

dyld: Symbol not found: _rb_intern2
  Referenced from: /Users/ktamas/.vim/ruby/command-t/ext.bundle
  Expected in: flat namespace

Vim: Caught deadly signal TRAP
Vim: Finished.
Trace/BPT trap

Comments

  1. Greg Hurrell

    Sounds to me like there is something pretty "funky" with your Ruby 1.9.1 install on that machine. The presence of the dynamic linker error convinces me that we're not talking about a bug in Command-T now, or a compatibility quirk that could be worked around, but actually a problem in your environment.

    I'm using the stock Ruby (1.8.7) that comes with Snow Leopard, but I also have a couple of other Ruby versions installed under ~/.multiruby using the multiruby from the ZenTest gem. So I can run the spec suite against different versions of Ruby but I've only done in-VIM testing using the stock Ruby that comes with the system. If I recall from your other ticket, your own tests in IRB worked fine, didn't they? It's only under VIM that there's a problem.

    The fact that the dynamic linker cannot resolve the rb_intern() function indicates to me that there's something pretty funky going on. It's like at the time you build the extension it's using one set of headers and libraries, but at the time of building MacVim it was using another, or perhaps at runtime it is using another. So I'd ask here:

    • How did you build MacVim (and what was the output of the build)?
    • How did you build Ruby 1.9.1 (and the output)?
    • What's the output when you do the ruby extconf.rb && make thing to build the Command-T extension?
    • What have you got set in your environment (ie. the output of export) and where is it coming from (ie. do you have anything in ~/.MacOSX/environment.plist?)
    • How are you launching MacVim (mvim? double-click? full path to /Applications/MacVim.app/Contents/MacOS/Vim?)

    I'm going to close your old ticket #1520 seeing as that exception doesn't exist in the codebase any more and we can continue here. (0.4 is out anyway, which doesn't include that particular check any more; but the dynamic linker error is indicative of a real problem because in a working install even if you pass a non-hash options parameter you should be seeing an exception, not a linker error.)

  2. anonymous

    Okay, so:

  3. KTamas

    the previous anonymous post was me, just forgot to log in...

  4. Greg Hurrell

    Ok, I don't have any direct experience with RVM (although I like the look of it!) but from the information you've pasted it looks like:

    • During the build of MacVim it found and used the files for the correct version of Ruby: 
    checking for ruby... /Users/ktamas/.rvm/rubies/ruby-1.9.1-p376/bin/ruby
checking Ruby version... OK
checking Ruby header files... /Users/ktamas/.rvm/rubies/ruby-1.9.1-p376/include/ruby-1.9.1
checking --enable-cscope argument... no
    • At least from the command line your environment has the PATH set up to look in the right place for Ruby binaries: 
    declare -x PATH="/sw/bin:/sw/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/Users/ktamas/.rvm/rubies/ruby-1.9.1-p376/bin:/Users/ktamas/.rvm/gems/ruby-1.9.1-p376/bin:/Users/ktamas/.rvm/gems/ruby-1.9.1-p376@global/bin:/Users/ktamas/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/X11R6/bin"
    • When building the extension the right version of Ruby was also consulted: 
    gcc -I. -I/Users/ktamas/.rvm/rubies/ruby-1.9.1-p376/include/ruby-1.9.1/i386-darwin10.2.0 -I/Users/ktamas/.rvm/rubies/ruby-1.9.1-p376/include/ruby-1.9.1/ruby/backward -I/Users/ktamas/.rvm/rubies/ruby-1.9.1-p376/include/ruby-1.9.1 -I. -DHAVE_RUBY_H  -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common  -O2 -g -Wall -Wno-parentheses -pipe -fno-common  -std=gnu99 -Wall -Wextra -Wno-unused-parameter -o ext.o -c ext.c

    If you were only using the GUI version of VIM then I would wonder if it's getting the same environment as the one you've got on the command line (that's why I asked about if you had anything in ~/.MacOSX/environment.plist), but I see you're testing from the command line...

    I am going to install RVM here and try to reproduce the problem here.

  5. Greg Hurrell

    Ok, the good news is I've been able to reproduce the problem and I am now fairly sure it's something to do with RVM, which should hopefully be easy enough to troubleshoot.

    Initial RVM set-up

    $ sudo gem install rvm
$ rvm-install
$ echo "if [[ -s /Users/wincent/.rvm/scripts/rvm ]] ; then source /Users/wincent/.rvm/scripts/rvm ; fi" >> ~/.bash_profile

    Then in a new shell:

    $ rvm install 1.9.1 # set up 1.9.1
$ rvm 1.9.1         # use 1.9.1 for the rest of the session

    Rebuild MacVim

    $ cd trabajo/vendor/MacVim/MacVim.git # this is my local clone of the MacVim Git repp
$ git pull # make sure it's up to date
$ make clean 
$ ./configure --with-features=huge --with-macarchs=i386 --enable-rubyinterp --enable-pythoninterp --enable-cscope --disable-nls
$ make
$ cd ~/.vim/ruby/command-t # now rebuild the Command-T extension
$ ruby extconf.rb 
$ make # and we're ready to try it out using the just-built MacVim
$ ~/trabajo/vendor/MacVim/macVim.git/src/MacVim/build/Release/MacVim.app/Contents/MacOS/Vim

    Here I get this error, which is what is usually shown when the extension can't be loaded and raises a LoadError: 

    command-t.vim could not load the necessary modules                                                                          
Please double-check the installation instructions
For more information type:  :help command-t

    So I add in a logging statement to see exactly what the error is and it's this: 

    #<LoadError: dlopen(/Users/wincent/.vim/ruby/command-t/ext.bundle, 9): no suitable image found.  Did find:^@^I/Users/wincent/.vim/ruby/command-t/ext.bundle: mach-o, but wrong architecture - /Users/wincent/.vim/ruby/command-t/ext.bundle>

    So looks like I have to drop the --with-macarchs=i386 from my configure invocation because the extension is probably getting built using an x86_64 arch. So after rebuilding MacVim and the extension we now get: 

    #<LoadError: no such file to load -- vim>dyld: lazy symbol binding failed: Symbol not found: _rb_intern2
  Referenced from: /Users/wincent/.vim/ruby/command-t/ext.bundle
  Expected in: flat namespace

dyld: Symbol not found: _rb_intern2
  Referenced from: /Users/wincent/.vim/ruby/command-t/ext.bundle
  Expected in: flat namespace

Vim: Caught deadly signal TRAP

Vim: Finished.
Trace/BPT trap

    So that's good; I've now reproduced the error.

    The missing _rb_intern2 symbol

    So I Google to see if I can find out more about this dynamic linker problem and find a number of results like these:

    That second one looks the most promising, and it's what makes me think this is actually an RVM thing. One of the tips there is to not use the RVM, but rather try the cutting-edge HEAD from the repp, so I'll do that presently and report back here.

  6. Greg Hurrell

    Now this is interesting:

    $ rvm use 1.9.1
$ ruby --version
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.2.0]
$ ~/trabajo/vendor/MacVim/macVim.git/src/MacVim/build/Release/MacVim.app/Contents/MacOS/Vim

    Now, inside VIM:

    :ruby p RUBY_VERSION
"1.8.7"
:ruby p ENV['PATH']
"/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/bin:/Users/wincent/.rvm/gems/ruby-1.9.1-p378/bin:/Users/wincent/.rvm/gems/ruby-1.9.1-p378%
global/bin:/Users/wincent/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/sbin:/Users/wincent/bin:/Devel
oper/Tools:/usr/X11R6/bin:/usr/local/mysql/bin:/usr/local/jruby/bin:/Users/wincent/bin/ec2-api-tools-1.3-46266/bin"

    So as you can see, even though we are apparently using 1.9.1 on the command line, once we get inside VIM it thinks we're using 1.8.7 despite the PATH being set to use 1.9.1 and also the fact that MacVim was built with 1.9.1 active.

  7. Greg Hurrell

    And more:

    $ otool -L ~/trabajo/vendor/MacVim/macVim.git/src/MacVim/build/Release/MacVim.app/Contents/MacOS/Vim
MacVim/build/Release/MacVim.app/Contents/MacOS/Vim:
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
	/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/System/Library/Frameworks/Python.framework/Versions/2.6/Python (compatibility version 2.6.0, current version 2.6.1)
	/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.13.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.14.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1038.25.0)

    Note the linkage against the system 1.8 Ruby.

  8. KTamas

    Wow. Weird. I guess i'll stop using RVM and install Ruby 1.9.1 through brew/macports/fink...

  9. Greg Hurrell

    Let me know how you go with that. I don't think it's necessarily specific for RVM, because I also tried with Multiruby and got identical results.

    In the meantime I posted to MacVim newsgroup asking for help:

    I figure that there might be people hanging around there that have experience with MacVim and 1.9.1.

  10. Greg Hurrell

    Summary changed:

    • From: MacVim and Command-T
    • To: Linker errors with MacVim and Ruby 1.9.1 ("dlyd: Symbol not found: _rb_intern2")
  11. Greg Hurrell

    Another post worth looking at, this one from the vim_dev group:

    Subject is "Ruby 1.9 compatibility status" and it's dated 10 February 2010. Pasting in the message body for reference: 

    All, 

Vim does not currently support integration with Ruby 1.9, 
but it's on the list (see :help todo). 

Masaki Suketa supplied a patch[1] to the vim_dev mailing list in 
July 2009, under the subject line "Patch for Vim with Ruby 1.9". 
Using this patch, I'm able to build Vim with support for Ruby 
1.9 (on Arch Linux), as well as Ruby 1.8 (on Fedora 12 Linux). 
The Ruby-based plugins I use (LustyExplorer[2] and 
LustyJuggler[3]) work fine Ruby 1.8 and Masaki's patch.  With 
Ruby 1.9, LustyExplorer is throwing an exception[4], but I think 
it's a problem with the plugin and the changing Ruby language 
definition, not a problem with integrating Ruby into Vim. 

Until Ruby 1.9 is supported in Vim, it will be more difficult 
for plugin authors to try Ruby 1.9 and fix any problems.  Arch 
Linux uses Ruby-1.9, so the Arch packager for Vim has disabled 
Ruby integration[5] pending a Vim patch that works with Ruby 
1.9.  This leave Arch users somewhat out in the cold for Ruby 
integration. 

Is Masaki's patch ready to be incorporated, or is more testing 
required?  Masaki had done testing with multiple versions of 
Ruby, including 1.8.7, 1.9.1, and 1.9.2dev.  It's working for me 
with Ruby 1.8 on Fedora, so it looks harmless for Ruby 1.8 
users, while allowing Ruby 1.9 users a chance to more widely 
exercise Ruby-based plugins and shake out compatibility bugs. 

Thanks, 
Michael Henry 

[1]: http://www.google.com/url?sa=D&q=http://groups.google.com/group/vim_dev/browse_thread/thread/699c65598bc6348b/e5c0a53a8a26624e%3Flnk%3Draot%26pli%3D1&usg=AFQjCNHvdVE_uVASeufLGbYEY2lWnXDCUA
[2]: http://www.vim.org/scripts/script.php?script_id=1890 
[3]: http://www.vim.org/scripts/script.php?script_id=2050 
[4]: The exception looks like this: 
      type mismatch: Fixnum given 
      (eval):118:in `index' 
      (eval):118:in `block in buildScoreArray' 
      (eval):117:in `each_byte' 
      (eval):117:in `buildScoreArray' 
      (eval):103:in `score' 
      (eval):326:in `block in matching_entries' 
      (eval):325:in `select' 
      (eval):325:in `matching_entries' 
      (eval):312:in `compute_ordered_matching_entries' 
      (eval):246:in `refresh' 
      (eval):222:in `key_pressed' 
      (eval):560:in `block in key_pressed' 
      (eval):492:in `time' 
      (eval):531:in `key_pressed' 
      (eval):1:in `<main>' 
[5]: http://bugs.archlinux.org/task/16710

    So perhaps you're trying to do something that isn't officially supported yet, but the patch linked to in the post might be enough to get you up and running?

  12. anonymous

    Okay, that's really messed up. Installed Ruby 1.9.1 with Brew, compiled MacVim with that... yet MacVim still defaults to the system Ruby 1.8.7 :((

  13. anonymous

    Oooooh... not supported, huh. Bleh. Gonna fall back to the system ruby 1.8.7, then....

  14. Greg Hurrell

    If you look at a few other tickets in the database you'll see that on some operating systems at least people are reporting success with 1.9.1:

    So I'm guessing that degree of "support" for 1.9.1 in VIM varies from platform to platform, as it is still very new. As I noted, 7.2 fails to compile miserably, but the trunk version from Subversion gets quite a bit further. I wouldn't be surprised if it works better on Linux than on Mac OS X. Perhaps very soon support on Mac OS X will get even better.

    For the time being however, I think I've made all the changes possible for 1.9.1 compatibility, so I'm going to mark this one as closed for now. I expect that once VIM's 1.9 support improves, the plug-in should work fine on it.

  15. Greg Hurrell

    Status changed:

    • From: new
    • To: closed
  16. Greg Hurrell

    For reference, thread in MacVim newsgroup asking if anybody has had success building MacVim with 1.9.1 support:

Add a comment

Comments are now closed for this issue.

Menu