I'm using CentOS 7.5. I just did a git pull in my clone of the vim repo to the latest: last tag v8.2.2340. I'm trying to compile. No matter what I do, it will not compile for the GUI (which it's always done before). Usually, I do nothing more than ./configure && make && sudo make install and all works.

After fiddling with the options to configure I still cannot get it to compile a GUI. I found this in the git log

commit 67876de7bbc4254268d8180d68203b965e25ed95 (tag: v8.2.2337)
Author: Bram Moolenaar <[email protected]>
Date:   Tue Jan 12 20:51:24 2021 +0100

    patch 8.2.2337: configure test for GTK only says "no"
    Problem:    Configure test for GTK only says "no". (Harm te Hennepe)
    Solution:   Hint that a -def package is needed. (closes #5229)

Apparently, someone else noted similar issues and the fix was to "hint" that -devel packages are needed. At least, I think they're talking about devel packages. The commit/tag comment says "-def" package. The problem, I have them.

$ rpm -qa gtk\*-deve\*

I want it to check for gtk2. The configure script is looking for gtk2 >= 2.2.0 but it always says "no," but yet version 2.24.31 is installed. What must I do to get the latest vim to compile for the GUI support that is installed on my system?

EDIT It would seem that the problem is due to the order of libraries for linking. I've been doing more digging and the config.log file shows several lines like this one when running the test for gtk2

/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpango-1.0.so: undefined reference to `g_object_replace_qdata'

This symbol is in the library libgobject.so which is installed on this system. Indeed, it's even used in the build line when linking. However, it cannot find these symbols. If I disable the GTK check, the configure script does find the GTK2 development libraries installed.

I think this all comes down to ld's irksome "order dependent on the command line" of libraries.

  • Yeah, the -dev suffix is what such packages are called in Debian/Ubuntu, that corresponds to the CentOS/RHEL/Fedora -devel suffix. That specific commit in 8.2.2337 is only printing additional messages and isn't changing the build behavior, so I somewhat doubt it that it's what is breaking your build... I do have a CentOS 7 build of Vim 8.2.1719 but it's using gtk3-devel and I'm passing --enable-gui=gtk3 to ./configure. Why do you want GTK2 instead of GTK3?
    – filbranden
    Jan 13, 2021 at 22:35
  • @filbranden I am using Mate Desktop. Since it's a fork of gnome2 I thought GTK 2 is what I should use. However, I'm likely admitting to my ignorance on GUIs. Are Gnome 2 and GTK2 the same? Jan 14, 2021 at 15:37
  • @filbranden well, I just tried with GTK3 and have the same unresolved symbols. Very strange. Jan 14, 2021 at 16:07
  • From my reading of the configure snippet, Vim should use the libraries listed in the output of pkg-config --libs gtk+-3.0 for linking. On my CentOS system, that's -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0. The g_object_replace_qdata symbol comes from -lgobject-2.0 (/usr/lib64/libgobject-2.0.so) which is included in package glib2-devel. Do you have all those packages installed?
    – filbranden
    Jan 14, 2021 at 18:09
  • 1
    @filbranden I finally found the answer. The problem came down to a local install of an older version of glib. It took some digging but I found a library reference for glib and one of the functions which I needed g_task_set_return_on_cancel. This function is from 2.36 onward. For reasons which I no longer recall, I'd installed 2.32, which went to /usr/local/lib which superseded the system library of 2.56. I'm rock'n the latest vim now. Jan 20, 2021 at 18:51

1 Answer 1


The answer came down to a local install of glib-2 which, because it was installed to /usr/local/lib was superseding the glib-2 installed in /lib64. As an example, a function named g_task_set_return_on_cancel which is part of glib v2.36 and later, was not found. I'd installed 2.32 (for reasons which I have presently forgotten) and it was superseding the system install of 2.58 in /lib64.

It could potentially have been solved in a variety of ways. Since I didn't recall why I installed 2.32 I simply removed it, reran configure for vim and rebuilt. An alternative method would have been to set LD_LIBRARY_PATH for the duration of the configure and build. Potentially, some variation of the magic arguments supported by configure may also be been used along with other env variables such as LDFLAGS or so forth.

Whatever potential solution you should find, if you find something like this, check for "local" installs which may be overshadowing the system install.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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