Your message dated Sat, 19 Aug 2023 08:09:30 +0200
with message-id <[email protected]>
and subject line Re: Bug#993380: lxc FTCBFS: compilation error in non-default
code path
has caused the Debian Bug report #993380,
regarding lxc FTCBFS: compilation error in non-default code path
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
993380: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993380
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: lxc
Version: 1:4.0.10-1
User: [email protected]
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
--- End Message ---
--- Begin Message ---
Version: 1:4.0.11-1
On Sat, Aug 19, 2023 at 01:44:53AM +0000, Mathias Gibbens wrote:
> Looking at http://crossqa.debian.net/src/lxc, it appears that this
> was fixed in version 4.0.11. Helmut, can you confirm? If so, let's
> close this bug.
Yes. In future, please just close FTCBFS bugs if you think they're
fixed without my confirmation. I can still reopen if I disagree.
Helmut
--- End Message ---
