Support ticket #1604: Can't install Command-T

command-t.vim could not load the C extension 

VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Mar  5 2010 15:46:30)
MacOS X (unix) version
Included patches: 1-376
Compiled by Bjorn Winckler <bjorn.winckler@gmail.com>
Huge version with MacVim GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl
+cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags
 +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() +fullscreen -gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
+mksession +modify_fname +mouse +mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg +odbeditor -osfiletype +path_extra -perl +postscript +printer
 +profile +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline
-sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar
+transparency +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows
 +writebackup -X11 -xfontset +xim -xsmp -xterm_clipboard -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-p
recomp  -g -O2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -arch x86_64 -D_FORTIFY_SOURCE=
1
Linking: gcc   -L.   -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -arch x86_64 -L/usr
/local/lib -o Vim -framework Cocoa -framework Carbon      -lm -lncurses  -liconv    -framework Python  -framework Ruby

/usr/bin/gcc-4.0 -I. -I/opt/local/lib/ruby/1.8/i686-darwin9.7.0 -I/opt/local/lib/ruby/1.8/i686-darwin9.7.0 -I. -DHAVE_RUBY_H -I/opt/local/include  -fno-common -O2  -fno-common -pipe -fno-common  -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.7.0 -I/opt/local/lib/ruby/1.8/i686-darwin9.7.0 -I. -DHAVE_RUBY_H -I/opt/local/include  -fno-common -O2  -fno-common -pipe -fno-common  -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.7.0 -I/opt/local/lib/ruby/1.8/i686-darwin9.7.0 -I. -DHAVE_RUBY_H -I/opt/local/include  -fno-common -O2  -fno-common -pipe -fno-common  -std=c99 -Wall -Wextra -Wno-unused-parameter -c matcher.c
cc -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    -lruby  -lpthread -ldl -lobjc 

Comments

1. Greg Hurrell 2010-07-12T05:23:14Z

   I gather from the /opt/local in the output of your make invocation that you are using some kind of package manager to provide a non-standard Ruby installation.

   I think the most likely cause, then, will be a discrepancy between the version of Ruby linked to by Vim (which I expect is the standard system Ruby via /System/Library/Ruby.framework) and the one linked to by the extension that you built.

   Can you try temporarily deactivating your package management system (I presume it inserts itself by altering your PATH or something, so just temporarily modify your PATH accordingly) and doing the make again? Then I'd expect it to work.

2. anonymous 2010-07-12T07:11:04Z

   Hi Wincent,

   Thanks so much for your quick reply!

   So after running a make distclean, then ruby extconf.rb and make again:

   gcc -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I. -DHAVE_RUBY_H   -fno-common -arch ppc -arch i386 -Os -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-darwin9.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I. -DHAVE_RUBY_H   -fno-common -arch ppc -arch i386 -Os -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-darwin9.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I. -DHAVE_RUBY_H   -fno-common -arch ppc -arch i386 -Os -pipe -fno-common  -std=c99 -Wall -Wextra -Wno-unused-parameter -c matcher.c
   cc -arch ppc -arch i386 -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 ppc -arch i386    -lruby  -lpthread -ldl -lm

   I still have no joy:

   "command-t.vim could not load the C extension"

3. Greg Hurrell 2010-07-12T07:32:06Z

   You could try manually loading the extension yourself from inside Vim and see if it reports more error info or throws an exception. Try:

   :ruby p(require 'command-t/ext')

   You should see either true (loaded successfully), false (was already loaded), or some exception message.

4. anonymous 2010-07-12T07:36:00Z

   LoadError: /Users/tcrins01/.vim/ruby/command-t/ext.bundle: dlopen(/Users/tcrins01/.vim/ruby/command-t/ext.bundle, 9): no suitable image found.  Did find:

5. Greg Hurrell 2010-07-12T07:44:59Z

   Hm. That's the kind of message you might see if you try loading a 64-bit extension into a 32-bit Ruby build, or vice versa.

   You could try forcing a 64-bit build like this:

   $ cd ~/.vim/ruby/command-t
   $ env ARCHFLAGS="-arch x86_64" ruby extconf.rb
   $ env ARCHFLAGS="-arch x86_64" make

   Probably a Snow Leopard vs Leopard thing. I've also got a 64-bit machine, but on Snow Leopard, and when I do ruby extconf.rb && make I get ARCHFLAGS of -arch i386 -arch x86_64 by default, whereas you are getting -arch ppc -arch i386:

   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

6. anonymous 2010-07-12T07:54:47Z

   Ahh! Perfect! That did the trick. Thank you so much for your help.

7. Greg Hurrell 2010-07-12T07:59:33Z

   Glad to hear it. Kind of annoying that the installation is so sensitive to that kind of discrepancy. Would love to find a way around it.

8. Greg Hurrell 2010-07-12T07:59:40Z

   Status changed:

   • From: new
   • To: closed

9. anonymous 2010-07-12T08:03:03Z

   Well if you need a test system, I can try to help? It is a shame, I saw the other issue that was just like this but couldn't think how to force the architecture.

10. Greg Hurrell 2010-07-12T08:13:08Z

    Thanks. Well the two possible ideas I have for this are:

    • install time: add some more checks either in the extconf.rb file or the Makefile itself, to at least catch the major likely causes of incompatibility and print some kind of warning
    • run time: add a command that can be called from inside Vim itself to try building the extension; at least that should rule out external package management systems as a possible cause

    Will try to get at least something like that sorted out before the 1.0 release.

11. anonymous 2010-07-12T08:22:05Z

    Either sound, like a good idea to me. I guess the problem is probably with the user though, I'm not the greatest linux user about so didn't know where to go. I think an obvious warning at install time would be the more standard approach? From a new to vim users perspective though I like the idea of vim installing it for me :)

Add a comment

Comments are now closed for this issue.