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

[Pierre-Elliott Bécue]

Helmut Grohne <helmut at subdivi.de> writes:

> 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.

Dear Helmut,

Thanks for your report and analysis. I admit I have not much time to
dive in the code and write the appropriate fix. Furthermore I guess it'd
be better if upstream fixed the issue.

Would you like me to forward the bug to their github issue tracker? If
you prefer I'm eager to do it. But to be honest, as you did the work, I
would prefer if you handled it, opening an issue on
https://github.com/lxc/lxc/issues .

If in your opinion there would be a preferred way to fix, please do
offer a patch! :)

Tell me what you'd prefer to do.

Thanks a lot!
--
PEB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 853 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20210902/6701ee4e/attachment.sig>