[pkg-lxc-devel] Bug#993380: lxc FTCBFS: compilation error in non-default code path

[Helmut Grohne]

Source: lxc
Version: 1:4.0.10-1
User: debian-cross at lists.debian.org
Usertags: ftcbfs

lxc used to cross build successfully, but no longer does. A build
includes the following snippet:

| libtool: compile:  powerpc64le-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../src -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPIC -Wvla -std=gnu11 -fms-extensions -fdiagnostics-color -Wimplicit-fallthrough=5 -Wcast-align -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection -fstack-protector-strong --param=ssp-buffer-size=4 -g -Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -Winit-self -Wunused-but-set-variable -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=return-type -Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels -Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow -Werror=shift-overflow=2 -Wdate-time -Wnested-externs -fasynchronous-unwind-tables -pipe -fexceptions -Warray-bounds -Wrestrict -Wreturn-local-addr -Wstringop-overflow -DLXCROOTFSMOUNT=\"/usr/lib/powerpc64le-linux-gnu/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/usr/libexec\" -DLIBEXECDIR=\"/usr/libexec\" -DLXCTEMPLATEDIR=\"/usr/share/lxc/templates\" -DLXCTEMPLATECONFIG=\"/usr/share/lxc/config\" -DLOGPATH=\"/var/lib/lxc\" -DLXC_DEFAULT_CONFIG=\"/etc/lxc/default.conf\" -DLXC_USERNIC_DB=\"/run/lxc/nics\" -DLXC_USERNIC_CONF=\"/etc/lxc/lxc-usernet\" -DDEFAULT_CGROUP_PATTERN=\"\" -DRUNTIME_PATH=\"/run\" -DSBINDIR=\"/usr/sbin\" -DAPPARMOR_CACHE_DIR=\"/var/cache/lxc/apparmor\" -I ../../src -I ../../src/lxc -I ../../src/lxc/storage -I ../../src/lxc/cgroups -DHAVE_APPARMOR -DHAVE_SECCOMP -DHAVE_SELINUX -DUSE_CONFIGPATH_LOGS -pthread -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wvla -std=gnu11 -fms-extensions -Werror -c criu.c  -fPIC -DPIC -o .libs/liblxc_la-criu.o
| In file included from criu.c:22:
| criu.c: In function ‘exec_criu’:
| log.h:378:2: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
|   378 |  LXC_ERROR(&locinfo, format, ##__VA_ARGS__);   \
|       |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| log.h:459:3: note: in expansion of macro ‘ERROR’
|   459 |   ERROR("%s - " format, ptr, ##__VA_ARGS__); \
|       |   ^~~~~
| log.h:493:3: note: in expansion of macro ‘SYSERROR’
|   493 |   SYSERROR(format, ##__VA_ARGS__);              \
|       |   ^~~~~~~~
| criu.c:324:11: note: in expansion of macro ‘log_error_errno’
|   324 |    return log_error_errno(-ENOMEM, ENOMEM, "Failed to remove extraneous slashes from \"%s\"", tmp);
|       |           ^~~~~~~~~~~~~~~
| cc1: all warnings being treated as errors
| make[4]: *** [Makefile:4606: liblxc_la-criu.lo] Error 1

Notably, this is not reproducible in a native build. Closer inspection
reveals that the faulty code is in a code path conditional to
!HAVE_M_FORMAT. That conditional is determined using AC_RUN_IFELSE
(because it determines a runtime property of the C library) and happens
to default to false during cross compilation. So on native glibc builds,
HAVE_M_FORMAT is true, but everywhere else it is false. Since it is
normally true, the other code path is untested and fails.

There are two notable methods to improve the situation. One is providing
a cache variable using AC_CACHE_CHECK. Doing so allows cross builders to
provide a result for this check as it is not otherwise testable in cross
builds. Another would be improving the defaults to just assume that %m
works on glibc when the test cannot be performed for cross building.
Finally, the !HAVE_M_FORMAT code path can be fixed.

As it is not obvious which route you want to take, I'm not including a
patch here. Rather, you have a detailed analysis with multiple options
to proceed. If you indicate a preference, I can turn it into a patch. Or
you simply fix it as it is not that difficult once the issue is
understood.

Helmut