Or cmocka-based CI relies on the ability to wrap functions calls, both
our own code and from and system libraries, with the --Wl,--wrap linker
flags. This works only if the function name in the function call generated
by the compliler is known. glibc has introduced function substitutions
for multiple system calls that break this assumption and thus break our CI.
For example, a C call to open() may be translated into a "call __open64_2"
assembly instruction.
We have first seen this with 7b217f8 ("multipath-tools: Makefile.inc:
set _FILE_OFFSET_BITS=64"), but also happens independently of the
type size macros. The 2nd patch in this series works around a
compiler-dependent substitution.
This has an unfortunate effect on our CI code, which is becoming
increasingly hard to understand, with lots of #if's with workarounds
combinations of library versions, compilers, and compile time settings.
CI failures have lately been caused much more frequently by this sort
of failure than by actual bugs in our own code, which is causing significant
maintenance effort.
I am not sure how to deal with this in the long term. I don't see a general
solution, although it's unlikely that only multipath-tools is affected by
this problem. For now, here are patches that fix the recent CI regressions.
Martin Wilck (2):
multipath-tools tests: fix CI failures on arm/v7 with glibc 2.37
multipath-tools tests: fix CI failures with clang on Fedora Rawhide
tests/directio.c | 22 +++++++++---------
tests/dmevents.c | 6 ++---
tests/sysfs.c | 58 ++++++++++++++++++++++++------------------------
tests/test-lib.c | 6 ++---
tests/vpd.c | 35 +++++++++++++++--------------
tests/wrap64.h | 37 +++++++++++++++++++++++++++++-
6 files changed, 100 insertions(+), 64 deletions(-)
--
2.44.0
