Re: glib2 deprecated declarations failing on clang16

Reply: Charlie Li : "Re: glib2 deprecated declarations failing on clang16"
In reply to: Nuno Teixeira : "Re: glib2 deprecated declarations failing on clang16"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Nuno Teixeira <eduardo_at_freebsd.org>
Date: Tue, 04 Jul 2023 14:50:54 UTC
(...)

Should this be applied upstream?
I could open a upstream PR about it.

Thanks,

Nuno Teixeira <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> 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> 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> 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> 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
>> > >>
>> > >> Build 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
>> >
>> >
>> >
>> > --
>> > Nuno Teixeira
>> > FreeBSD Committer (ports)
>>
>>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)