Glib linking problem on installation of gobject-introspection

[Paul_Emsley]

Using Alma Linux 8.9, gcc 8.5.0

On trying to compile and install gobject-introspection 1.80.0:

meson setup -Dprefix=$install_top_dir build

As part of the process, ‘glib’ is cloned and installed.

The resulting binaries, glib-compile-schemas in particular, is linked with the wrong libglib-2.0.so (see that it is linked with the system libglib and libgobject instead of the library recently installed ~/autobuild/Linux-pc.internal-gtk4/lib64/libglib-2.0.so).

glib-compile-schemas is complied with new glib headers, so this causes a problem down the line when compiling pygobject:

~/autobuild/Linux-pc.internal-gtk4/bin/glib-compile-schemas: symbol lookup error: /home/pemsley/autobuild/Linux-pc.lmb.internal-gtk4/bin/glib-compile-schemas: undefined symbol: g_ptr_array_sort_values

ldd ~/autobuild/Linux-pc.internal-gtk4/bin/glib-compile-schemas
linux-vdso.so.1 (0x00007ffc6a95e000)
libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f4c349e3000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f4c346c9000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f4c34476000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4c340b1000)
libffi.so.6 => /lib64/libffi.so.6 (0x00007f4c33ea8000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f4c33ca4000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4c33aa0000)
libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007f4c336af000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f4c3343e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4c3321e000)
libz.so.1 => /lib64/libz.so.1 (0x00007f4c33006000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f4c32ddb000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f4c32bc3000)
libmount.so.1 => /lib64/libmount.so.1 (0x00007f4c32969000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4c32751000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4c34d8d000)
libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f4c32427000)
libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f4c32209000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f4c31e88000)
libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f4c31c75000)
libnettle.so.6 => /lib64/libnettle.so.6 (0x00007f4c31a3b000)
libhogweed.so.4 => /lib64/libhogweed.so.4 (0x00007f4c3180b000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f4c34eff000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f4c31587000)
libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f4c31334000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4c3112c000)
librt.so.1 => /lib64/librt.so.1 (0x00007f4c30f24000)

Is this a bug in glib or in gobject-introspection or my failure to use meson correctly?

Is this the cirular dependency problem? i.e. I need to install glib first?

Dealing with GLib and gobject-introspection circular dependency

Starting with GLib 2.79.0 and gobject-introspection 1.79.0, there is a circular dependency between the two projects. GLib depends on the introspection tools for generating the introspection data of its library components and documentation, and gobject-introspection depends on GLib (mainly: libglib, libgobject, and libgmodule) for the introspection tools. The recommendation for distributors is to stage the build in the following way: build GLib with -Dintrospection=disabled build gobject-intro…

Thanks.

[ebassi (Emmanuele Bassi)]

Do not build GLib as a subproject of gobject-introspection, especially if you already have an installed GLib.

The process to build GLib and gobject-introspection is:

1. build GLib with -Dintrospection=disabled and install it in the desired prefix
2. build gobject-introspection and install it in the same prefix
3. build GLib again with -Dintrospection=enabled, and install it in the same prefix

Yes, you need to build GLib twice. Yes, it’s a cycle. Yes, it’s currently unavoidable. Yes, it’s being addressed and will likely be fixed in the next cycle.

[Paul_Emsley]

Thank you for your reply.

It seems as if I’m missing something.

I went back and tried to install just GLib (your step 1). I was unable to get GLib to link against its own libraries. This is what I tried:

    glib_version=2.79.3
    glib_version_dir=2.79
    echo BUILDING: glib $glib_version without introspection
    wget -nv -N https://download.gnome.org/sources/glib/$glib_version_dir/glib-$glib_version.tar.xz
    tar xf glib-$glib_version.tar.xz
    cd glib-$glib_version
    if meson setup -Dprefix=$install_top_dir -Dintrospection=disabled build ; then
        cd build
        ninja
        ninja install
        cd -
    fi
    cd -

However, the resulting glib-compile-schemas is (still) linked with the system GLib, not its own.

I am puzzled, it is not typical for a package not to use its own libraries (at least in my experience) - how do the GLib developers address this? This is not a very googleable issue.

Edit: Having done a bit more reading, perhaps I should be using JHBuild? (I would like, eventually to build and use the latest and greatest GTK4).