assertion getting __xstat64 on rawhide

[hadess]

On Fedora 34, we get an error trying to run the upower test suite:

make[4]: Leaving directory '/builds/upower/upower/_build/src'
env GI_TYPELIB_PATH=../libupower-glib: LD_LIBRARY_PATH=../libupower-glib/.libs: top_builddir=.. ../../src/linux/integration-test
umockdev: could not get libc function __xstat64

See https://gitlab.freedesktop.org/upower/upower/-/jobs/5142881

[hadess]

I used the new debug in https://github.com/martinpitt/umockdev/pull/107 to get that nice error message.

[martinpitt]

I just added CI for fedora:{latest,rawhide}, and with the current container images it worked, so that's a fairly recent regression. I'll now add a dnf update to the containers. Locally on rawhide it doesn't even build any more, due to the same root cause:

src/libumockdev-preload.c:1357:14: error: no previous prototype for ‘__lxstat’ [-Werror=missing-prototypes]
 1357 | WRAP_VERSTAT(__lx,);
      |              ^~~~

(and some more for variants)

Edit: With dnf update it now fails as intended.

[martinpitt]

Not actually sure why it would fail at runtime -- the symbol still exists:

❱❱❱ rpm -qf  /usr/lib64/libc.so.6
glibc-2.32.9000-12.fc34.x86_64

❱❱❱ nm -D /usr/lib64/libc.so.6|grep xstat64
00000000000f1810 T __fxstat64@@GLIBC_2.2.5
00000000000f1870 T __lxstat64@@GLIBC_2.2.5
00000000000f17b0 T __xstat64@@GLIBC_2.2.5

Failing at build time is expected -- that glibc version dropped that entire xstat*() family. Dropping binary compatibility is a bit evil, though. However, your run used 2.32.9000-11.fc34 , current is -12, and that indeed reverted that symbol removal.

So I think it's not super-duper urgent, and if you retry your pipeline it should work. But of course the build still needs to be fixed. I'll do that more cleanly though, instead of a knee-jerk hack, and do a new release by Monday (still travelling/PTO).

[hadess]

Thanks for looking into it so quickly!

[martinpitt]

Hmm, this is really tricky.. glibc 2.32.9000-11.fc34 dropped the declaration, but still has the symbols. Thus one can't use AC_CHECK_LIB with that, and instead I came up with this hack:

AC_MSG_CHECKING([whether libc has __xstat() function])
# this will *fail* to compile on a prototype mismatch if __xstat() is defined;
# otherwise succeed with a warning (implicit declaration)
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <sys/stat.h>], [__xstat("")])],
     [have_xstat=no], [have_xstat=yes])
AC_MSG_RESULT($have_xstat)
if test "$have_xstat" = yes; then
    AC_DEFINE_UNQUOTED([HAVE__XSTAT], [1], [whether libc has __xstat() function])
fi

--- src/libumockdev-preload.c
+++ src/libumockdev-preload.c
@@ -1351,7 +1351,7 @@ WRAP_3ARGS(ssize_t, -1, readlink, char *, size_t);
 WRAP_4ARGS(ssize_t, -1, getxattr, const char*, void*, size_t);
 WRAP_4ARGS(ssize_t, -1, lgetxattr, const char*, void*, size_t);

-#ifdef __GLIBC__
+#ifdef HAVE__XSTAT
 WRAP_VERSTAT(__x,);
 WRAP_VERSTAT(__x, 64);
 WRAP_VERSTAT(__lx,);

This fixes the compilation, but does not fix runtime -- other software like udevadm of course still links to/uses __xstat64() and friends, and thus umockdev ceases to work.

I think I want/need to make this less compile-time and more run-time detected.

[martinpitt]

I threw this around a few times, and I didn't find a way to make it work with 2.32.9000-11.fc34. Without glibc defining the symbol, programs that call __xstat() through umockdev will just cause a linker error, regardless of where it is detected. So I just fixed the build against version -12 now.

[martinpitt]

I released 0.14.4 with this fix.