Control: tags -1 + patch
Control: forwarded -1 https://github.com/brummer10/gxtuner/issues/19
(Adrian: I don't intend to cc you on responses to all bugs of this class,
but I thought I'd cc you on the first one so that you can see what I'm
recommending as a solution.)
On Mon, 16 Aug 2021 at 13:33:01 +0300, Adrian Bunk wrote:
> In file included from /usr/include/glib-2.0/glib/gatomic.h:31,
> from /usr/include/glib-2.0/glib/gthread.h:32,
> from /usr/include/glib-2.0/glib/gasyncqueue.h:32,
> from /usr/include/glib-2.0/glib.h:32,
> from /usr/include/glib-2.0/gobject/gbinding.h:28,
> from /usr/include/glib-2.0/glib-object.h:22,
> from ./gxtuner.h:33,
> from gxtuner.cpp:24:
> /usr/include/c++/10/type_traits:56:3: error: template with C linkage
> 56 | template<typename _Tp, _Tp __v>
> | ^~~~~~~~
> In file included from gxtuner.cpp:24:
> ./gxtuner.h:30:1: note: ‘extern "C"’ linkage started here
> 30 | extern "C" {
> | ^~~~~~~~~~
Bugs with this compiler error are caused by a header behaviour change
in GLib 2.68.
In older versions, the GLib headers contained only C code, even when
compiled with a C++ compiler. In GLib 2.68+, if C++ compilation is
detected, the headers make use of C++ features to make macros like
g_object_ref() more type-safe.
There are two ways to resolve the build failure:
1. Move inclusions of system headers outside extern "C" blocks, at least
for well-behaved libraries like GLib and GTK that already include their
own extern "C" guard, either directly or via macros like GLib's own
G_BEGIN_DECLS/G_END_DECLS.
Attached patch 0001-Move-system-header-inclusions-outside-extern-C.patch
implements this. I've proposed it upstream.
2. Target a specific GLib version by defining the macros
GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED (see GLib's
documentation for details). This asks GLib to disable behaviour changes
and deprecation warnings that happened since the target version.
Attached patch 0001-build-Target-a-specific-GLib-API-version.patch
implements this. I've proposed it upstream. The choice of GLib 2.54
is completely arbitrary (it's the version that was current at the time
gxtuner was most recently released) so an upstream or downstream
maintainer could probably make a better choice.
Maintainers can choose either or both of those methods. I would personally
recommend doing both.
I've successfully compiled gxtuner against GLib 2.68.3 with each of those
patches, individually. I have not otherwise tested the resulting executables.
Thanks,
smcv
