Gtk4 installation failure (old glib2)

Hi, I’m trying to install gtk4 for the first time (CentOS7 x8664) so I can begin migrating my gtk3 apps, but the command ‘meson setup --prefix /opt/gtk builddir’ fails with the error

Dependency glib-2.0 found: NO found 2.56.1 but need: ‘>= 2.66.0’

I am already using the latest CentOS 7.9 el7 x86_64 RPMs for glib2 (2.56.1 as noted). I have located Fedora source RPMs for 2.6{6,7} glib2 releases but I am very concerned about introducing incompatibilities into my system as the current 2.56.1 RPMs appear to have a huge number of dependencies. (The latter presumably include my gtk3 enviroment which I want. to continue using.)

Any ideas? I’m open to installing a newer Linux distro into another VM on my host if that would simplify things, but I would like if possible to wind up with an environment where I can test my apps under both gtk3 and gtk4. Breaking my existing CentOS7 VM would be a disaster which I need to avoid at all costs.

Thanks!

If you’re willing to use Flatpak, you have a great option. GNOME Builder can be installed on CentOS 7 using Flatpak which will provide you a SDK environment (also using Flatpak) for GTK 4 development. The org.gnome.Sdk master builds already have GTK 4 available within them.

You’re system will be isolated from changes and your app will have a predictable runtime with all the dependencies met.

Thanks, Christian! I know nothing about flatpak, am investigating now …

Roger

Hi Christian,

I was able to install the Gnome Builder flatpak, but I’m not sure this is what I want. I know nothing about flatpak OR Builder so I’m miles out of my depth here, but it appears that running ‘flatpak run org.gnome.Builder’ is basically starting up an IDE, correct? Unfortunately I’ve never been a fan of IDEs and I’ve got a couple dozen medium-to-large-ish gtk3 apps with their own Makefiles referencing numerous non-GUI libraries, etc., where I really just want to change my Makefiles to link against gtk4 instead of gtk3 and find/fix whatever’s busted as I build and test within my pre-existing development framework.

Quite possibly I’m misunderstanding this completely, please advise if so! If I am understanding correctly and anyone can recommend an appropriate Linux distro to install on a VM that will include all of the dependencies needed to build the gtk4 development libraries (or at least allow me to externally obtain and install any necessary dependencies without breaking the distro), that would be my preferred solution.

Thanks!

Roger

Regarding an appropriate Linux distro on which to attempt gtk4 4.0 installation, it looks to me like Fedora33 may be a good candidate in terms of its package versions (glib2, etc.) in relation to what gtk4’s meson.build file seems to want. It also already has a 3.99.2 version of gtk4 installed along with gtk3. Hopefully this bodes well for installing gtk4 4.0 while maintaining gtk3 in parallel, so I think I’ll start here unless anyone with experience has any recommendations to the contrary.

I think generally meson should work for you. For my gentoo box I have now these instruction list:

# https://discourse.gnome.org/t/installing-gtk4-for-testing-on-opt-ii/3349/4
cd
rm -rf /opt/gtk
rm -rf gtk
rm -rf gtksourceview
rm -rf vte
rm -rf libhandy
rm -rf libnice
rm -rf pango
rm -rf dconf
rm -rf gstreamer

cd
git clone https://gitlab.gnome.org/GNOME/gtk.git
cd gtk
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

cd
git clone https://gitlab.gnome.org/GNOME/vte.git
cd vte
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

cd
git clone https://gitlab.gnome.org/GNOME/libhandy.git
cd libhandy
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

cd
git clone https://gitlab.freedesktop.org/libnice/libnice.git
cd libnice
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

cd
git clone https://gitlab.gnome.org/GNOME/pango.git
cd pango
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

cd
git clone https://gitlab.gnome.org/GNOME/dconf.git
cd dconf
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

cd
git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git
cd gstreamer
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

export GI_TYPELIB_PATH=/opt/gtk/lib64/girepository-1.0
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gtk/lib64/
#export GSETTINGS_SCHEMA_DIR=/opt/gtk/share/glib-2.0/schemas /opt/gtk/bin/gtk4-demo
export PKG_CONFIG_PATH="/opt/gtk/lib64/pkgconfig/"

cd
git clone https://gitlab.gnome.org/GNOME/gtksourceview.git
cd gtksourceview
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

Indeed my default glib is OK, so meson does not install a glib. But I think meson should do that if necessary. Once it did not work for me, but that was an issue with an old meson version. And I have always to remove the source directories and start from scratch. Updating with git pull often does not work for me.

Hi Stefan,

Thanks for that information, and in fact I was already following your instructions from one of your earlier postings to this forum! Your help is much appreciated. After my meson build failed I found this dependency list inside the meson.build file:

glib_req = ‘>= 2.66.0’
pango_req = ‘>= 1.47.0’ # keep this in sync with .gitlab-ci/test-msys.sh
fribidi_req = ‘>= 0.19.7’
cairo_req = ‘>= 1.14.0’
gdk_pixbuf_req = ‘>= 2.30.0’
introspection_req = ‘>= 1.39.0’
wayland_proto_req = ‘>= 1.20’
wayland_req = ‘>= 1.14.91’
graphene_req = ‘>= 1.9.1’
epoxy_req = ‘>= 1.4’
cloudproviders_req = ‘>= 0.3.1’
xkbcommon_req = ‘>= 0.2.0’
sysprof_req = ‘>= 3.38.0’

After discovering this I started rummaging through Linux distro package lists and the first distro I found which appeared to satisfy the requirements was Fedora 33, so I am now installing a Fedora 33 VM on my host for this effort and will re-run your meson build instructions after Fedora is installed.

meson made no effort to install a compatible glib2 on my CentOS 7.9 system and I am very glad that it did not, as I cannot afford to trash that system with a glib2 update that may be wildly incompatible with other software.

Thanks!

Installation of Fedora 33 into a VM followed by gtk4 installation has gone well (mostly, at least, see next paragraph). It turns out that a ‘yum install gtk4-devel’ somehow even finds a pre-packaged RPM of the current 4.0 release (meaning that I don’t have to build from source with meson) so that was an unexpected treat. The system now appears to have development environments for both gtk3 and gtk4 in happy co-existence. Unfortunately I have a sizeable codebase and am still wading through necessary non-gtk patches required to get all to compile under Fedora, so I will be a while with that before I can start updating my GUI code to gtk4. It does appear, however, that I may be in pretty good shape with regard to a usable gtk4 development environment. Thanks to all here for their helpful suggestions!

Too bad that Fedora 33 itself seems rather unstable, at least in my VM installation (VMWare Fusion on macOS Catalina). I am getting lots of system GUI freeze-ups (nothing related to gtk4) requiring constant reboots. Found hints on the web about disabling 3D graphics acceleration in my VM config but that has not helped me. I expect to spend a number of happy hours on the phone with VMWare support next week to figure out what’s going on. Many years ago we switched from Fedora to CentOS due to stability issues, now I’m beginning to remember why. ;-(

I can not solve your issue, but I can tell you what I do in general. I actually compile from
source, using lots of ruby scripts. (I can not recommend my own scripts to others,
though, because they are just a mega-pile of hacks.)

When you have a “clean” environment, compiling and installing things is actually
quite easy.

I am quite sure gtk4 has other named .so files.

For example, in my directory /home/Programs/Gtk/Current/lib/ for gtk 4.0.1
I only have libgtk-4.so, libgtk-4.so.1 and libgtk-4.so.1.0.1; and three directories,
one being just pkgconfig/ (which would normally then go into /usr/lib/pkgconfig).
The .h header files are under the include/ directory there.

I am getting lots of system GUI freeze-ups
I had this a bit too when using GNOME3 on fedora. If GTK3 works for you I’d
recommend not investing too much time into any transition yet. But using
GTK3 and GTK4 should be possible at the same time. I even have gtk2 here
and it works via ruby-gtk2 bindings. :slight_smile: (gtk3 looks nicer though)

Thanks for the suggestions, Robert!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.