Source: bamf
Version: 0.5.4-1
Severity: important
Tags: ftbfs
Control: block 940161 by -1
To reproduce, build bamf against glib2.0 2.62.x, currently in experimental.
glib2.0 2.62.x is part of GNOME 3.34 and will be uploaded to unstable soon,
at which point this bug will become RC.
bamf uses compiler options that include -Werror and
-Wno-error=deprecated-declarations:
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall -std=c99 -fPIC -DDATADIR=\"/usr/share\"
> -I. -I../../lib -I../../lib -pthread -I/usr/include/gio-unix-2.0
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2
> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -Werror -Wno-error=deprecated-declarations
> -Wempty-body -Wformat-security -Winit-self -Warray-bounds
> -Wimplicit-function-declaration -lm -c bamf-application.c -fPIC -DPIC
> -o .libs/libbamf3_la-bamf-application.o
GLib 2.62.x has started to apply deprecation warning markers to
deprecated non-declaration constructs, such as macros and types. In
particular this affects the G_TYPE_INSTANCE_GET_PRIVATE macro,
which is part of the implementation of older conventional macros like
BAMF_APPLICATION_GET_PRIVATE. Because this is not actually a declaration,
it is unaffected by -Wno-error=deprecated-declarations:
> bamf-application.c: In function ‘bamf_application_class_init’:
> bamf-application.c:714:3: warning: ‘g_type_class_add_private’ is deprecated
> [-Wdeprecated-declarations]
> 714 | g_type_class_add_private (obj_class, sizeof
> (BamfApplicationPrivate));
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
> from /usr/include/glib-2.0/gobject/gbinding.h:29,
> from /usr/include/glib-2.0/glib-object.h:23,
> from /usr/include/glib-2.0/gio/gioenums.h:28,
> from /usr/include/glib-2.0/gio/giotypes.h:28,
> from /usr/include/glib-2.0/gio/gio.h:26,
> from ../../lib/libbamf-private/bamf-gdbus-generated.h:11,
> from ../../lib/libbamf-private/bamf-private.h:23,
> from bamf-application.c:38:
> /usr/include/glib-2.0/gobject/gtype.h:1308:10: note: declared here
> 1308 | void g_type_class_add_private (gpointer
> g_class,
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> bamf-application.c: In function ‘bamf_application_init’:
> bamf-application.c:746:13: error: G_ADD_PRIVATE [-Werror]
> 746 | priv = self->priv = BAMF_APPLICATION_GET_PRIVATE (self);
> | ^~~~~~~~~~~~~~~
The obvious solution is to stop compiling distro packages with -Werror,
which is nearly always a RC bug waiting to happen. Untested patch:
edit this line in configure.ac
CFLAGS="$CFLAGS -Wall -Werror -Wno-error=deprecated-declarations
-Wempty-body -Wformat-security -Winit-self -Warray-bounds
-Wimplicit-function-declaration -lm"
and remove -Werror.
Unfortunately this setup *appends* to CFLAGS rather than using a separate
variable or prepending to CFLAGS, so it is not possible to avoid -Werror
by using "make CFLAGS=-Wno-error" or similar. Autotools best-practice
is to reserve CFLAGS for use by the user, and use a separate variable
for flags requested by the upstream maintainer. It would probably
be worthwhile to talk to upstream about a more distro-friendly setup
for CFLAGS, such as using a separate variable like WARNING_CFLAGS for
the compiler warnings, using the standard Libtool macro LT_LIB_M to
populate $(LIBM) instead of hard-coding -lm, and having a straightforward
way to disable -Werror - or perhaps using the autoconf-archive macro
AX_COMPILER_FLAGS, which adds a --disable-Werror option suitable for
use by distros.
smcv
