glib-compile-resources crashes on Linux 4.19
When trying to build software using glib resources, like VTE, I get a crash in glib-compile-resources like the following:
[92/207] /usr/bin/glib-compile-resources ../vte-0.74.2/src/app/app-gtk3.gresource.xml --sourcedir src/app --sourcedir ../vte-0.74.2/src/app --c-name app --internal --generate --target src/app/resources-gtk3.cc.c --dependency-file src/app/resources-gtk3.cc.c.d
FAILED: src/app/resources-gtk3.cc.c
/usr/bin/glib-compile-resources ../vte-0.74.2/src/app/app-gtk3.gresource.xml --sourcedir src/app --sourcedir ../vte-0.74.2/src/app --c-name app --internal --generate --target src/app/resources-gtk3.cc.c --dependency-file src/app/resources-gtk3.cc.c.d
(glib-compile-resources:303): GLib-WARNING **: 09:46:19.731: ../glib-2.78.3/glib/gmain.c:5934: waitid(pid:304, pidfd=4) failed: Invalid argument (22). See documentation of g_child_watch_source_new() for possible causes.
../vte-0.74.2/src/app/app-gtk3.gresource.xml: Child process exited abnormally.
If I downgrade to glib 2.76.4, then everything works fine.
I traced the issue to commit f615eef4. Apparently this pidfd solution does not work on 4.9.337, which I suppose is expected since the commit message talks about >=5.3. The problem is that the selection of implementation is done compile-time using the cpp symbol HAVE_PIDFD
, which is set by the following meson.build
code:
if cc.links('''#include <sys/syscall.h>
#include <sys/wait.h>
#include <linux/wait.h>
#include <unistd.h>
int main (int argc, char ** argv) {
siginfo_t child_info = { 0, };
syscall (SYS_pidfd_open, 0, 0);
waitid (P_PIDFD, 0, &child_info, WEXITED | WNOHANG);
return 0;
}''', name : 'pidfd_open(2) system call')
glib_conf.set('HAVE_PIDFD', 1)
endif
So this only checks that the code can be compiled, not that it actually works on the system. And even if this was a cc.run
, there would still be a problem with the choice being made compile time if the resulting binary was moved to a different system with a different kernel version. For this to be portable between kernel versions there would have to be some sort of runtime check.