Meson/ninja GTK4 built error

I tried just to update GTK4, as usual with

cd gtk
git pull
meson --prefix /opt/gtk builddir
ninja -C builddir
ninja -C builddir install

The ninja -C builddir now gives

prof-source.c.o -c ../subprojects/sysprof/src/libsysprof/sysprof-memprof-source.c
../subprojects/sysprof/src/libsysprof/sysprof-memprof-source.c: In function ‘sysprof_memprof_source_modify_spawn’:
../subprojects/sysprof/src/libsysprof/sysprof-memprof-source.c:43:36: error: ‘PACKAGE_LIBDIR’ undeclared (first use in this function)
   43 |     static const gchar so_path[] = PACKAGE_LIBDIR"/libsysprof-memory-"API_VERSION_S".so";
      |                                    ^~~~~~~~~~~~~~
../subprojects/sysprof/src/libsysprof/sysprof-memprof-source.c:43:36: note: each undeclared identifier is reported only once for each function it appears in
../subprojects/sysprof/src/libsysprof/sysprof-memprof-source.c:43:50: error: expected ‘,’ or ‘;’ before string constant
   43 |     static const gchar so_path[] = PACKAGE_LIBDIR"/libsysprof-memory-"API_VERSION_S".so";
      |                                                  ^~~~~~~~~~~~~~~~~~~~~
[17/1572] Compiling C object subprojects/sysprof/src/libsysprof/libsysprof-4.so.p/.._libsysprof-capture_sysprof-capture-reader.c.o
ninja: build stopped: subcommand failed.

I have meson-0.55.1. Is that already too old, or may it be another problem?

Your sysprof subproject hasn’t been updated, so it’s probably an older commit. PACKAGE_LIBDIR is defined in the sysprof/meson.build file.

You will need at least commit d6aabaf1ff9fc24c7754feb1dcbb4f4285d4da8b in the subproject.

My recommendation is to delete subprojects/sysprof, and re-run Meson.

3 Likes

Thanks for your fast reply. Only delete subprojects/sysprof did not really helped, but your hint with sysprof was very good. So my actual fix is something like

cd
rm -rf /opt/gtk
rm -rf gtk

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

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gtk/lib64/
export PKG_CONFIG_PATH="/opt/gtk/lib64/pkgconfig/"

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

sysprof install asked in last step “ninja -C builddir install” for root password, what is a bit strange as there is write access for user on /opt, but I allowed root access for sysprof and it worked.

The important point seems to be: First install recent sysprof and set PKG_CONFIG_PATH="/opt/gtk/lib64/pkgconfig/"

Then continue with gtk.

When gtk4 demos still runs not fine, like wrong font size, then it may be necessary to install latest dconf with

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

I would recommend using jhbuild to set up a build environment under a separate prefix, and handle all the possible dependencies.

1 Like

I have already considered using jhbuild.

But the reason why I install GTK4 currently at all is for testing the Nim bindings, and for that the test environment should be identical to a native installation, that is to the situation which we will have when large distros like gentoo, arch, ubuntu, debian will finally ship GTK4. My impression was that with jhbuild we launch our apps in a special testing environment. Well I think most distros will ship GTK4 soon, so the effort installing it to /opt will not be needed any more.

I still wonder why root keyword was needed to finish my install to /opt, as I can write to /opt as user. Root password was requested for sysprof, gtk and dconf install. It may be related to latest python 3.7 maybe, some weeks ago all worked fine without root password request, but my gentoo box was updated recently. Root password request is really bad as so we may damage our whole system.

Hi,

I have the same issue, but from the 3.99.1 tarball. Is there any way of building this on a 3.36 environment without having to install the latest venison of sysprof? In fact, is sysprof now a hard dependency? I can see the sysprof option is still there in meson_options.txt, but it doesn’t seem to work when I explicitly disable it.

Probably the same problem as mentioned in https://gitlab.gnome.org/GNOME/gtk/-/issues/3108

This has been fixed in the main development branch.

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