Problems under MacVim Snapshot 52

  1. anonymous

    I have been using the command-t plugin for a while now with MacVim 7.2 stable 1.2, but recently decided to try Snapshot 52. In Snapshot 52 i get the error:

    command-t.vim could not load the C extension
    Please see INSTALLATION and TROUBLE-SHOOTING in the help
    For more information type:    :help command-t  

    After reading the trouble shooting section as it suggests, I am still stuck. I don't believe it is a problem of 32 bit vs 64 bit. I'm not sure how to tell if Snapshot 52 was compiled against a different version of Ruby than stable 1.2.

    I am running OS X 10.5.8 and my main ruby installation is ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin9].

    Any direction on the matter would be greatly appreciated. I have really enjoyed using the plugin and hope I can eventually get it to work with Snapshot 52.

    Thank you!

    - Nick

  2. Greg Hurrell

    I'm using snapshot 52 here so I don't think it's necessarily a problem with that.

    You can see which version of Ruby MacVim was linked against by doing:

    :ruby p RUBY_VERSION

    It should print something like:

    "1.8.7"

    What do you see when you do:

    $ cd ~/.vim/ruby/command-t
    $ ruby extconf.rb
    $ make

    You should see something vaguely like this, and if not, hopefully the output will contain a clue as to why the extension isn't being built or can't be loaded by VIM:

    gcc -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0 -I. -DHAVE_RUBY_H  -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -arch i386 -arch x86_64 -g -Os -pipe -fno-common -DENABLE_DTRACE  -fno-common  -pipe -fno-common   -std=c99 -Wall -Wextra -Wno-unused-parameter -c ext.c
    gcc -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0 -I. -DHAVE_RUBY_H  -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -arch i386 -arch x86_64 -g -Os -pipe -fno-common -DENABLE_DTRACE  -fno-common  -pipe -fno-common   -std=c99 -Wall -Wextra -Wno-unused-parameter -c match.c
    gcc -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0 -I. -DHAVE_RUBY_H  -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -arch i386 -arch x86_64 -g -Os -pipe -fno-common -DENABLE_DTRACE  -fno-common  -pipe -fno-common   -std=c99 -Wall -Wextra -Wno-unused-parameter -c matcher.c
    cc -arch i386 -arch x86_64 -pipe -bundle -undefined dynamic_lookup -o ext.bundle ext.o match.o matcher.o -L. -L/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib -L. -arch i386 -arch x86_64     -lruby  -lpthread -ldl  
  3. anonymous

    Hello,

    From running :ruby p RUBY_VERSION, I get:

    "1.8.6"

    From make I get:

    /usr/bin/gcc-4.0 -I. -I/opt/local/lib/ruby/1.8/i686-darwin9 -I/opt/local/lib/ruby/1.8/i686-darwin9 -I. -DHAVE_RUBY_H -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -O2 -arch i386  -fno-common -pipe -fno-common  -arch i386 -std=c99 -Wall -Wextra -Wno-unused-parameter -c ext.c
    /usr/bin/gcc-4.0 -I. -I/opt/local/lib/ruby/1.8/i686-darwin9 -I/opt/local/lib/ruby/1.8/i686-darwin9 -I. -DHAVE_RUBY_H -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -O2 -arch i386  -fno-common -pipe -fno-common  -arch i386 -std=c99 -Wall -Wextra -Wno-unused-parameter -c match.c
    /usr/bin/gcc-4.0 -I. -I/opt/local/lib/ruby/1.8/i686-darwin9 -I/opt/local/lib/ruby/1.8/i686-darwin9 -I. -DHAVE_RUBY_H -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -O2 -arch i386  -fno-common -pipe -fno-common  -arch i386 -std=c99 -Wall -Wextra -Wno-unused-parameter -c matcher.c
    /usr/bin/gcc-4.0 -dynamic -bundle -undefined suppress -flat_namespace -o ext.bundle ext.o match.o matcher.o -L. -L/opt/local/lib -L. -L/opt/local/lib  -arch i386  -lruby  -lpthread -ldl -lobjc  

    It seems that make is using the ruby I installed from MacPorts while MacVim is using Ruby from somewhere else. What's odd about that though, is both Snapshot 52 and Stable 1.2 say 1.8.6, so I don't know why it would work in one, but not the other.

    Thank you for your help

  4. Greg Hurrell

    Seems that the most likely cause of the crash is the incompatibility between the version of Ruby linked against by VIM and the version used to compile the extension.

    I'll bet that if you remove the MacPorts stuff from your PATH temporarily in order to build the extension that it will work.

    Not a MacPorts user myself, so not sure how to do that exactly, but basically something like this:

    $ echo $PATH
    $ OLD_PATH=$PATH
    $ export PATH=... # here supply a PATH with all/any "/opt/local" paths removed
    $ cd ~/.vim/ruby/command-t
    $ ruby extconf.rb
    $ make
    $ export PATH=$OLD_PATH

    If you do it right, you should see /System/Library/Frameworks/Ruby.framework referenced in the build commands, and I expect the plug-in will work fine in VIM.

  5. anonymous

    When I removed everything having to do with MacPorts from my path, ruby extconf.rb was unable to find ruby.h

    I installed rvm yesterday (after this whole issue started), so I tried installing ruby 1.8.6 through that and compiling the plugin so that the versions would match. I go the same result however, with Stable working and the Snapshot broken. It doesn't make any sense to me though because both version of MacVim say they're running 1.8.6, so I don't know why one would work and one wouldn't.

    Thanks, Nick

  6. Greg Hurrell

    I think I read that in one of the recent snapshots Björn changed to doing 64-bit builds or something, especially with respect to Snow Leopard or something (can't remember the exact details). It might be worth looking at the snapshot release notes but I have to go away for the weekend so I can't do that right now.

    So it might be a 32-bit vs 64-bit thing. What kind of machine you running on? Is it a 64-bit one (eg. recent iMac?) or an older 32-bit one.

  7. Greg Hurrell

    Ok, back again.

    The three latest release announcements, as far as I can tell:

    This build requires an Intel Mac running 10.6 or later. When 7.3 is released I will build another version that runs on earlier versions of OS X and which supports PPC.

    A warning: it is possible that this release will break Ruby plugins due to a patch to mainline Vim (which changed return types of certain functions from String to Fixnum). For example, the LustyExplorer plugin broke because of this (but has subsequently been patched). At any rate, if you have any problems with Ruby plugins after updating to snapshot 52 you should contact the plugin maintainer.

    (Not really any notes for that snapshot that seem relevant...)

    Before you get your hopes up, the comments about changes in the Ruby stuff in 52 aren't an issue for Command-T, as it was fixed way back on 6 March, before Command-T 0.1 had even been released (and the day after the MacVim snapshot release).

    So, sadly, the release notes don't really shed any additional light here.

  8. anonymous

    Alright well I'm pretty stuck on what's going on here... I have been putting off upgrading to Snow Leopard, but it seems this might be fixed by doing so. I'll just use stable until then.

    Thanks for your help!

  9. Greg Hurrell

    Yeah, sorry I couldn't give you a definitive answer.

    I still believe the most likely cause is a mismatch. One last thing you could try is actually building MacVim from source. Might be opening a can of worms, but it would be one way of ensuring that the version of Ruby MacVim links against is the same version that the Command-T extension links against when you compile it.

    Made some brief notes on compiling it in "Building MacVim from source".

    About the only other thing I can suggest is that perhaps you might find a clue in some of the tickets elsewhere on the site (for example, ticket #1528). Different people on different platforms, and usually the cause is a mismatch which they eventually solve.

    But yeah, sticking with the stable release might just be the sanest thing to do.

Reply

This topic is now closed.