1

I recently upgraded from Unbuntu 18.x to 20.x and I'm trying to compile vim with the following features:

  • +lua
  • +python
  • +python3
  • +ruby

but I haven't been able to get it to go through.

Looking through the output, I notice the following lines:

checking --enable-fail-if-missing argument... no
checking --enable-luainterp argument... no     
checking --enable-pythoninterp argument... no                                                                                                                                                                                                  
checking --enable-python3interp argument... no   
checking --enable-rubyinterp argument... no       

However, the config script I'm running explicitly contains those options. I've tried using a =yes and =dynamic syntax as well

  function gitupdatevim() {
    cd /usr/share/vimgit
    sudo make clean distclean
    sudo git pull --all
    gitvimconfigandmake | tee ~/gitupdatevim_$(date -d "today" +"%Y%m%d%H%M%S").txt

  }

  function gitvimconfigandmake() {
    sudo ./configure \
      --with-features=huge \
      --enable-fail-if-missing \
      --enable-cscope \
      --enable-fontset \
      --disable-gui \
      --enable-multibyte \
      --enable-largefile \
      \
      # Lua
      --enable-luainterp \
      --with-lua-prefix=/usr/include/lua5.3 \
      # --with-luajit \
      \
      # Python2
      --enable-pythoninterp \
      # --enable-pythoninterp=yes \
      # --enable-pythoninterp=dynamic \
      --with-python-command=python2.7 \
      --with-python-config-dir=/usr/lib/python2.7/config-x86_64-linux-gnu \
      \
      # Python3
      --enable-python3interp \
      # --enable-python3interp=yes \
      # --enable-python3interp=dynamic \
      --with-python3-command=python3.8 \
      --with-python-config-dir=$(python3-config --configdir) \
      \
      # Ruby
      --enable-rubyinterp

    sudo make
    sudo make install
    # sudo make clean distclean
    \vim --version

  }

Just to confirm, the version output:

Lua

$ lua -v
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio

$ whereis lua
lua: /usr/bin/lua5.2 /usr/bin/lua /usr/bin/lua5.3 /usr/bin/lua5.1 /usr/lib/x86_64-linux-gnu/lua /usr/include/lua5.2 /usr/include/lua5.3 /usr/include/lua5.1 /usr/share/lua5.2 /usr/share/lua5.3 /usr/share/lua5.1 /usr/share/man/man1/lua.1.gz

Python2

$ python -V
Python 2.7.18

$ whereis python
python: /usr/bin/python3.6m /usr/bin/python2.7 /usr/bin/python3.6 /usr/bin/python3.8 /usr/bin/python /usr/bin/python3.8-config /usr/lib/python2.7 /usr/lib/python3.6 /usr/lib/python3.8 /usr/lib/python3.9 /etc/python2.7 /etc/python3.6 /etc/python3.8 /etc/python /usr/local/lib/python2.7 /usr/local/lib/python3.6 /usr/local/lib/python3.8 /usr/include/python2.7 /usr/include/python3.8 /usr/share/python

Python3

$ python3 -V
Python 3.8.10

$ whereis python3
python3: /usr/bin/python3.6m /usr/bin/python3.6 /usr/bin/python3 /usr/bin/python3.8 /usr/bin/python3.8-config /usr/lib/python3.6 /usr/lib/python3 /usr/lib/python3.8 /usr/lib/python3.9 /etc/python3.6 /etc/python3 /etc/python3.8 /usr/local/lib/python3.6 /usr/local/lib/python3.8 /usr/include/python3.8 /usr/share/python3 /usr/share/man/man1/python3.1.gz

Ruby

$ ruby --version
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]

$ whereis ruby
ruby: /usr/bin/ruby2.7 /usr/bin/ruby /usr/lib/x86_64-linux-gnu/ruby /usr/lib/ruby /home/linux/.rvm/rubies/ruby-3.0.0/bin/ruby /usr/share/man/man1/ruby.1.gz

What could be messing things up here?

It's worth noting that I DID have an interruption during the sudo do-release-upgrade cycle. It was while it was waiting for user input regarding one of the "this upgrade contains a new version of this file. Do you want to keep your original, use the new one, compare differences, etc?"

I re-ran the upgrade again, but ran into numerous errors afterward that I seemed to be able to fix with a few commands, including

$ sudo dpkg --configure -a
$ sudo apt install -f

And Vim DID have the +lua, +python, etc features before the upgrade when I was previously on 18.x

This makes me wonder if the upgrade interruption had something to do with it. Maybe I should have kept the original files in the prompts rather than going with the new ones?


UPDATE: \vim --version output

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jun 16 2022 15:24:01)
Included patches: 1-5114
Compiled by linux@linux-VirtualBox
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl               +file_in_path      +mouse_urxvt       -tag_any_white
+arabic            +find_in_path      +mouse_xterm       -tcl
+autocmd           +float             +multi_byte        +termguicolors
+autochdir         +folding           +multi_lang        +terminal
-autoservername    -footer            -mzscheme          +terminfo
+balloon_eval      +fork()            +netbeans_intg     +termresponse
+balloon_eval_term +gettext           +num64             +textobjects
+browse            -hangul_input      +packages          +textprop
++builtin_terms    +iconv             +path_extra        +timers
+byte_offset       +insert_expand     -perl              +title
+channel           +ipv6              +persistent_undo   +toolbar
+cindent           +job               +popupwin          +user_commands
+clientserver      +jumplist          +postscript        +vartabs
+clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +vim9script
+cmdline_hist      +langmap           -python            +viminfo
+cmdline_info      +libcall           -python3           +virtualedit
+comments          +linebreak         +quickfix          +visual
+conceal           +lispindent        +reltime           +visualextra
+cryptv            +listcmds          +rightleft         +vreplace
+cscope            +localmap          -ruby              +wildignore
+cursorbind        -lua               +scrollbind        +wildmenu
+cursorshape       +menu              +signs             +windows
+dialog_con_gui    +mksession         +smartindent       +writebackup
+diff              +modify_fname      -sodium            +X11
+digraphs          +mouse             +sound             -xfontset
+dnd               +mouseshape        +spell             +xim
-ebcdic            +mouse_dec         +startuptime       +xpm
+emacs_tags        +mouse_gpm         +statusline        +xsmp_interact
+eval              -mouse_jsbterm     -sun_workshop      +xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary        
-farsi             -mouse_sysmouse    -tag_old_static    
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -O2 -fno-strength-reduce -Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 
Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lselinux -lcanberra -lacl -lattr -lgpm -ldl 

Update: For convenience, here are links to vim's source files on compiling

Makefile https://github.com/vim/vim/blob/master/src/Makefile

Install Unix https://github.com/vim/vim/blob/master/src/INSTALLx.txt

3
  • 3
    as mentioned on the reddit. You need to make sure to install the development libraries. Check this FAQ entry: vimhelp.org/vim_faq.txt.html#faq-35.10 Jun 17 at 9:22
  • Thank you Christian for both replies! I'll follow-up once done, fingers crossed! :)
    – Spectator6
    Jun 17 at 15:58
  • @ChristianBrabandt that did the trick! Throw it in as an answer if you want and I'll give you the updoots :) Thanks again, you've helped this be a productive Friday!
    – Spectator6
    Jun 17 at 16:06

2 Answers 2

3

This usually happens, if you do not have the development versions of those interpreters installed. It's not enough to have those interpreters available, but during the compilation of Vim, the compiler needs to understand the interfaces and structures for including those features. That's why your compilation succeeds without those features even so you have given the correct argument flags for the configure script1.

If you want to know in detail why those interpreters were disabled during compilation, you have to check the configure log which should be located in the src/auto/config.log file in the the checked out repository. But there is an easier way to include (at least most of those interpreters automatically). Your linux distribution usually provides a flavor of vim with most features and interpreters turned on, so it already knows, what libraries are required for building and linking. This means, you can call your package manager with a special command to have all those compilation requirements installed. Note: to be able to use the following commands, you need to have enabled source repository URLs (e.g. on Debian it requires deb-src URLs in apt's sources list configuration).

  1. On Debian like systems, this should be: sudo apt-get build-dep vim-gtk3. This should allow you to build a vim with lua, python3, perl, ruby and tcl, only python2 and mzscheme is missing (which may no longer so important, since python2 is end-of-life for some time already). If you want those interpreters as well, you need to manually find out what libraries are required by checking the configure log as mentioned above.

  2. On OpenSUSE you should be able to use the following command: zypper source-install --build-deps-only vim

  3. On Fedora/RedHat/CentOS like distributions, you should be able to use yum-builddep vim-enhanced

  4. Not sure about other distributions like Arch, but most likely they provide something similar.

Note: the name of the package may have changed over time (e.g. previously Debian provided a package vim-gtk which used to provide a graphical vim with most interpreters turned on and GTK2 gui enabled. But nowadays this is just a transitional package and will pull in the vim-gtk3 package which is the same but with a GTK3 enabled gui. Same might be true for the other distributions.) It's been some time when I collected those information, so this may have changed in the meantime.

Most of this is also mentioned in the VIM-FAQ Q:35-10. If some of this is no longer accurate, please consider opening a PR with improvements at the vim_faq source repository and feel free to improve this answer here as well.


1 If you want configure to fail, if those interfaces cannot be included when building (instead of just disabling those), you need to use the --enable-fail-if-missing configure argument.

7
  • Thank you for such a thorough write-up @Christian!
    – Spectator6
    Jun 19 at 19:44
  • @Spectator6 given the length of your edit and the summary, I'm inclined to think it should be its own answer with references to/citations from Christian's answer.
    – D. Ben Knoble
    Jun 22 at 20:55
  • (@Spectator6 RE: bash-fu, with new enough bash you can use arrays. So you can do (for example), conf_options=(--option1\n--option2\n#comment\n--option3), where \n means newline.)
    – D. Ben Knoble
    Jun 22 at 20:56
  • 1
    @Spectator6 Try your profile > All actions (left bar) > click the "suggested edit reject" part of the row. You can also try looking under "Revisions" in the All Actions bit. If that doesn't work, LMK and I'll find a way to get you the text.
    – D. Ben Knoble
    Jun 23 at 14:28
  • 1
    Found it, thank you @D.BenKnoble! :)
    – Spectator6
    Jun 23 at 19:38
0

After struggling through this process a bit more while testing out my install scripts, I want to share some additional insights that may be helpful for others.

  1. I seemed to have numerous apt install <package> commands silently failing throughout the process. I only realized this when, after reaching my wits end, I started manually typing portions of the install script into the terminal. And that's when I noticed it would continue to install NEW packages. "New packages? NEW? What? I CLEARLY had these same install commands in the script..."

    I suspect this is because a "failed" install causes the remainder of the line to silently abort. So for example...

    $ sudo apt install <good_package> <good_package> <BAD_package> <good_package> <good_package>...

    The <BAD_package> would prevent all subsequent install attempts, meaning only the first TWO <good_package>'s would be installed.

    And that's when I discovered the && syntax. I don't know if this is the best way to approach this, but for now, instead of having a long install command spread out over multiple lines, I broke everything out individually, with each command proceeded by -y &&. My understanding thusfar is that this essentially tells the script to continue on to the next command ONLY if the preceding command was successful. So for example...

    $ sudo apt install <good_package> -y &&
    $ sudo apt install <good_package> -y &&
    $ sudo apt install <BAD_package> -y &&
    $ sudo apt install <good_package> -y &&
    ...
    

    This would return an error, clearly letting me know the <BAD_package> could not be found. Which led me to use a newer version or whatever the case may be.

  2. Something else I noticed is that the way I was formatting the .configure options in my install scripts seems to be problematic. I previously was using what I thought to be a valid multi-line syntax by placing a \ at the end of each line, but evidently that doesn't play very well. Also, for whatever reason, trying to place comments within the command to help in readability seems to be a no-no. So for example...

    sudo ./configure \
      --option1 \
      --option2 \
      \ #Descriptive text
      --option3 \
      ...
    

    Does not work.

    Instead, I have to keep it all on one continuous line and NOT have any comments, like

    sudo ./configure --option1 --option2 --option3 ...

    And I only figured this out when, just like before, I reached my wits end and resorted to manually typing out the configure line into the console by hand rather than rely on the script.

Granted, these may be fairly well-known concepts, but to a gcc noob like myself, these two user-driven errors took me multiple days of bashing my head against the wall to stumble upon.

That said, if there's any more "bash" or "gcc make" related kungfu I can add to my quiver or even more productive ways to handle the above situations (something more reliable than && to achieve what I'm after?), I'm all ears :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.