Date: Tue, 4 Jul 2023 15:56:34 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Nuno Teixeira <eduardo@freebsd.org> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: glib2 deprecated declarations failing on clang16 Message-ID: <BBD89BC1-8E9D-4E6D-887E-4A785F4A21D4@FreeBSD.org> In-Reply-To: <CAFDf7U%2B-M1D7xL_AkB-eY%2B0jq2JjjdhzoZUZtnmanVoa25vOtQ@mail.gmail.com> References: <CAFDf7U%2B-M1D7xL_AkB-eY%2B0jq2JjjdhzoZUZtnmanVoa25vOtQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_8E89F3A0-5F02-41DA-BB4C-7674DF2F5283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 4 Jul 2023, at 14:37, Nuno Teixeira <eduardo@freebsd.org> wrote: >=20 > I'm getting build errors from current with www/bluefish about = deprecated glib2 declarations and causing build to fail with clang16: > --- > /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded = from macro 'G_DEPRECATED' > #define G_DEPRECATED __attribute__((__deprecated__)) > ^ > mv -f .deps/bluefish.Tpo .deps/bluefish.Po > bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is = deprecated: Use 'g_thread_new' instead [-Wdeprecated-declarations] > g_thread_create_full(build_bflang2scan_thread, NULL, 0, FALSE, = FALSE, G_THREAD_PRIORITY_LOW, &gerror); > --- >=20 > Any help is welcome on finding out its cause. >=20 > a related issue: https://github.com/PCSX2/pcsx2/issues/3315 >=20 > Build log: = https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c5842= 5_s0631830a7a/logs/bluefish-2.2.14.log The actual error is an incompatible callback function signature: bftextview2_autocomp.c:432:2: error: incompatible function pointer types = passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int (struct = _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka = 'void (*)(void)') [-Wincompatible-function-pointer-types] g_signal_connect(acw->reflabel, "activate-link", = acw_label_active_link_lcb, acw); = ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~ /usr/local/include/glib-2.0/gobject/gsignal.h:515:59: note: expanded = from macro 'g_signal_connect' g_signal_connect_data ((instance), (detailed_signal), (c_handler), = (data), NULL, (GConnectFlags) 0) ^~~~~~~~~~~ /usr/local/include/glib-2.0/gobject/gsignal.h:411:25: note: passing = argument to parameter 'c_handler' here GCallback c_handler, ^ I have seen these more often with glib-based applications. In some cases it is feasible to fix the callback function to have the correct signature, in other cases you can slap a cast in place. Or, if the affected code is vala-generated (also happens), the big hammer is to suppress the warning(s). -Dimitry --Apple-Mail=_8E89F3A0-5F02-41DA-BB4C-7674DF2F5283 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZKQlEgAKCRCwXqMKLiCW o/dRAKDiLq0mw6scN5AkIf/cRMPZm2fVRACdG9eUAzo073jrPzWLnOXc9WKLdsA= =Se67 -----END PGP SIGNATURE----- --Apple-Mail=_8E89F3A0-5F02-41DA-BB4C-7674DF2F5283--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BBD89BC1-8E9D-4E6D-887E-4A785F4A21D4>