Re: glib2 deprecated declarations failing on clang16
Date: Tue, 04 Jul 2023 17:33:36 UTC
Nuno Teixeira wrote:
> (...)
>
> Should this be applied upstream?
> I could open a upstream PR about it.
>
After looking through some history on the glib side (which have been
fixing incompatible function pointer conditions as they appear),
G_CALLBACK() should be applied to bluefish. Upstreaming is a good idea.
> Nuno Teixeira <eduardo@freebsd.org <mailto:eduardo@freebsd.org>>
> escreveu no dia terça, 4/07/2023 à(s) 15:42:
>
> And run test sucess at main-n263935-e8423423737e
>
> I will do more testport builds with gtk2 and gtk3.
>
> I will use something like in commit msg:
> ---
> Fix build with clang16
> Use G_CALLBACK() macro to silence incompatible function pointer
> warnings and
> disables any argument checks.
>
> Reported by: dim
> ---
>
> Cheers,
>
> Dimitry Andric <dim@freebsd.org <mailto:dim@freebsd.org>> escreveu
> no dia terça, 4/07/2023 à(s) 15:31:
>
> I got to exactly the same patches. This is due to how glib's
> gclosure.h
> header declares its callback function type as '(void)', even
> though in
> reality the number and type of the arguments varies:
>
> /**
> * GCallback:
> *
> * The type used for callback functions in structure
> definitions and function
> * signatures.
> *
> * This doesn't mean that all callback functions must take
> no parameters and
> * return void. The required signature of a callback function
> is determined by
>
> * the context in which is used (e.g. the signal to which
> it is connected).
> *
> * Use G_CALLBACK() to cast the callback function to a
> #GCallback.
> */
> typedef void (*GCallback) (void);
>
> It would have been better if glib had just used '(...)', but the
> solution they have chosen requires each callback function to be cast
> using the G_CALLBACK() macro.
>
> That basically shuts up any incompatible function pointer
> warnings, and
> disables any argument checks.
>
> -Dimitry
>
> > On 4 Jul 2023, at 16:21, Nuno Teixeira <eduardo@freebsd.org
> <mailto:eduardo@freebsd.org>> wrote:
> >
> > Hello Danilo!
> >
> > Yes, it builds ok.
> >
> > I will do a run test tomorrow on bluefish.
> >
> > Any hint on how to explain it in commit:
> >
> > ---
> > --- src/bftextview2_autocomp.c.orig 2023-07-04 14:09:37 UTC
> > +++ src/bftextview2_autocomp.c
> > @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
> > /*gtk_widget_set_size_request(acw->reflabel,150,-1); */
> > gtk_widget_show_all(acw->scroll);
> > gtk_widget_show(hbox);
> > - g_signal_connect(acw->reflabel, "activate-link",
> acw_label_active_link_lcb, acw);
> > + g_signal_connect(acw->reflabel, "activate-link",
> G_CALLBACK(acw_label_active_link_lcb), acw);
> >
> /*gtk_widget_set_size_request(GTK_WIDGET(acw->tree),100,200); */
> > /*gtk_widget_set_size_request(acw->win, 150, 200); */
> >
> /*g_signal_connect(G_OBJECT(acw->win),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw); */
> > ---
> > and
> > ---
> > --- src/external_commands.c.orig 2023-07-04 14:12:18 UTC
> > +++ src/external_commands.c
> > @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep,
> const gchar * fo
> >
> gtk_dialog_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);
> > tmp = g_strdup_printf(_("Supply arguments to
> define %%a in '%s'"), formatstring);
> > entry = dialog_entry_labeled(NULL, tmp,
> gtk_dialog_get_content_area(GTK_DIALOG(dialog)), 6);
> > - g_signal_connect(G_OBJECT(entry), "activate",
> command_dialog_entry_activated_lcb, dialog);
> > + g_signal_connect(G_OBJECT(entry), "activate",
> G_CALLBACK(command_dialog_entry_activated_lcb), dialog);
> > g_free(tmp);
> > gtk_widget_show_all(dialog);
> > result = gtk_dialog_run(GTK_DIALOG(dialog));
> > ---
> >
> > Thanks!
> >
> > Danilo Egea Gondolfo <danilo@freebsd.org
> <mailto:danilo@freebsd.org>> escreveu no dia terça, 4/07/2023
> à(s) 15:00:
> > On 04/07/2023 14:56, Dimitry Andric wrote:
> >
> > > On 4 Jul 2023, at 14:37, Nuno Teixeira <eduardo@freebsd.org
> <mailto:eduardo@freebsd.org>> wrote:
> > >> 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);
> > >> ---
> > >>
> > >> Any help is welcome on finding out its cause.
> > >>
> > >> a related issue:
> https://github.com/PCSX2/pcsx2/issues/3315
> <https://github.com/PCSX2/pcsx2/issues/3315>
> > >>
> > >> Build log:
> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log <https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_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
> > >
> > Not a glib expert here, but you can try this
> https://pastebin.com/ty8hLjVU <https://pastebin.com/ty8hLjVU>
> >
> >
> >
> > --
> > Nuno Teixeira
> > FreeBSD Committer (ports)
>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
--
Charlie Li
…nope, still don't have an exit line.