From nobody Tue Jul 04 14:50:54 2023 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QwQhp4XRrz4lhBS for ; Tue, 4 Jul 2023 14:51:06 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QwQhp4M8gz3mRp; Tue, 4 Jul 2023 14:51:06 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1688482266; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=owmwjwF/hfQG387kh3mw4h7Whj1skECGDr1MOJBn/po=; b=oYdxvLJlEB5zl+FxfVR/0Js2TRKqo0PmWMrbg34zJQ/ipc7EV0zwPkCJ6AG0/ky/S3Uf05 WBGk7XVreXphVo/1jJJs69jCD+RjLjVA5ozTCi6XZjjUUniuanMD3NNaFHkO9PnXrQn/Td Af/hSP9aaILRLbjojzhO5S+zElCSgPC/EgSuVST0Lw3BE93ZtNnNnGJOdI54Xsw54ma2et 8gPDcvB32n5GzDgoPvTeAAjlq7pcfY8oMQ1HerZt7TV3OuG571hf1dhlFKjNNokTu5JeS0 jzsqggPBzQvzoIxWLY5066GCy43yVANufpU/ijMA4++cXPgKpJ67gzLraU2SRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1688482266; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=owmwjwF/hfQG387kh3mw4h7Whj1skECGDr1MOJBn/po=; b=lPWvhBQeNrBoghoVk+mLkkQIRUYmGRFy44twzYE3eDM5cVepopTeVGCijjHQmRlW74fsSx NfCAaTJqSx9Q4Skb2WRMkU9hIOTW6p66hV6+s+SlyvOneO+do6UxHPSOWvZW3AgyZNb+4D lHPqLG2IxPWkFoO9zEHRxbPv9qtOwtTbNilNX+YlkwhOGxHaFSXQwv70geStyR7INr8ku8 Cy+HVTyksvJMxPFTtQJi6hYn4gVAUK4UlU130mjMj8Y9r2oFYohwrFHZs1liOsmnY96RGR mOONDMLO86kjlGLWLh+++rynYE4syNPEZkzpNLcLD6Dz09TEob5pSfw/s08UvA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1688482266; a=rsa-sha256; cv=none; b=K5rJUYOvDxjcnMezOVqEd6Yt/RaUfETrvtgpmF2JWiOlnkJptxwFLAEoDyBuQ9rHmN0RAN KTjJRKdMgWMGAsZHpfXsCM3MzRXtvN3pGijMOk2qO3ib6RLktxAnw5UpYGjthg6/JXX57q jE0XyWmOXL3piiseubFZst6PrFeF9Tjr3g7OytBP+s8qQ8jg1wIsSHIV6o88D8qYI2ncmr LS0zcsZf4yc0LWM9g0DBwhdH2qlB5OthQswF5k/lUsmj6uDVZr1RzDfeJHUvSVS5JnQt33 To8JFn69dl4pekCPCTRocv3AFHh+PKAlFNEyH7bwvS8H2qb9aKK8X37lL/6PEQ== Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QwQhp3HxWzHlJ; Tue, 4 Jul 2023 14:51:06 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-402f748bfafso38109161cf.2; Tue, 04 Jul 2023 07:51:06 -0700 (PDT) X-Gm-Message-State: AC+VfDx38L1siSdXOufKAtd3TLv4E9+TNDoM5E9xcXLGvwtugHdYBwV8 yMfu5tQQs8q+QbLTJXMz6FRYaL0YeeCzt265eIc= X-Google-Smtp-Source: ACHHUZ5xBrQfLyGMw24QbSqfGAlzSZgAsB0fjHZXVUym2MmN4scHB/DwrFfDYHI9k/s2B1/+r+qEcJacixEEvMxWpvs= X-Received: by 2002:a05:622a:1901:b0:3f6:c202:b009 with SMTP id w1-20020a05622a190100b003f6c202b009mr16349242qtc.8.1688482265794; Tue, 04 Jul 2023 07:51:05 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <22F61A7B-3566-4761-8D7A-DC78B9CF20E6@FreeBSD.org> In-Reply-To: From: Nuno Teixeira Date: Tue, 4 Jul 2023 15:50:54 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: glib2 deprecated declarations failing on clang16 To: Dimitry Andric Cc: Danilo Egea Gondolfo , FreeBSD Ports Content-Type: multipart/alternative; boundary="000000000000a9911205ffaa69dd" X-ThisMailContainsUnwantedMimeParts: N --000000000000a9911205ffaa69dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Should this be applied upstream? I could open a upstream PR about it. Thanks, Nuno Teixeira escreveu no dia ter=C3=A7a, 4/07/2023 = =C3=A0(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 escreveu no dia ter=C3=A7a, 4/07/2023 = =C3=A0(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 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(ac= win_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 =3D g_strdup_printf(_("Supply arguments to define = %%a >> in '%s'"), formatstring); >> > entry =3D 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 =3D gtk_dialog_run(GTK_DIALOG(dialog)); >> > --- >> > >> > Thanks! >> > >> > Danilo Egea Gondolfo escreveu no dia ter=C3=A7a, >> 4/07/2023 =C3=A0(s) 15:00: >> > On 04/07/2023 14:56, Dimitry Andric wrote: >> > >> > > On 4 Jul 2023, at 14:37, Nuno Teixeira 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/pf46bd2c58= 425_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 (stru= ct >> _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka 'vo= id >> (*)(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) > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000a9911205ffaa69dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)

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

Thanks,

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia ter=C3=A7a, 4/07= /2023 =C3=A0(s) 15:42:
And run test sucess at main-n263935-e842342373= 7e

I will do more testport builds with gtk2 and gt= k3.

I will use something like in commit msg:
=
---
Fix build with clang16
Use G_CALLBACK() ma= cro to silence incompatible function pointer warnings and
disables any argument checks.

Reported by: dim
---

=
Cheers,

Dimitry Andric <dim@freebsd.org> escreveu no dia ter=C3= =A7a, 4/07/2023 =C3=A0(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:

=C2=A0 /**
=C2=A0 =C2=A0* GCallback:
=C2=A0 =C2=A0*
=C2=A0 =C2=A0* The type used for callback functions in structure definition= s and function
=C2=A0 =C2=A0* signatures.
=C2=A0 =C2=A0*
=C2=A0 =C2=A0* This doesn't mean that all callback functions must take = no=C2=A0 parameters and
=C2=A0 =C2=A0* return void. The required signature of a callback function i= s determined by=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * the context i= n which is used (e.g. the signal to which it is connected).
=C2=A0 =C2=A0*
=C2=A0 =C2=A0* Use G_CALLBACK() to cast the callback function to a #GCallba= ck.
=C2=A0 =C2=A0*/
=C2=A0 typedef void=C2=A0 (*GCallback)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (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=C2=A0 =C2=A0 =C2=A02023-07-04 14:0= 9:37 UTC
> +++ src/bftextview2_autocomp.c
> @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*gtk_widget_set_size_request(acw->= ;reflabel,150,-1); */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_widget_show_all(acw->scroll);<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_widget_show(hbox);
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_connect(acw->reflabel, "a= ctivate-link", acw_label_active_link_lcb, acw);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_connect(acw->reflabel, "a= ctivate-link", G_CALLBACK(acw_label_active_link_lcb), acw);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*gtk_widget_set_size_request(GTK_WID= GET(acw->tree),100,200); */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*gtk_widget_set_size_request(acw->= ;win, 150, 200); */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*g_signal_connect(G_OBJECT(acw->w= in),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw); *= /
> ---
> and
> ---
> --- src/external_commands.c.orig=C2=A0 =C2=A0 =C2=A0 =C2=A0 2023-07-04= 14:12:18 UTC
> +++ src/external_commands.c
> @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep, const gchar = * fo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_dialo= g_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tmp =3D g= _strdup_printf(_("Supply arguments to define %%a in '%s'"= ), formatstring);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entry =3D= dialog_entry_labeled(NULL, tmp, gtk_dialog_get_content_area(GTK_DIALOG(dia= log)), 6);
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_conne= ct(G_OBJECT(entry), "activate", command_dialog_entry_activated_lc= b, dialog);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_conne= ct(G_OBJECT(entry), "activate", G_CALLBACK(command_dialog_entry_a= ctivated_lcb), dialog);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g_free(tm= p);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_widge= t_show_all(dialog);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0result = =3D gtk_dialog_run(GTK_DIALOG(dialog));
> ---
>
> Thanks!
>
> Danilo Egea Gondolfo <danilo@freebsd.org> escreveu no dia ter=C3=A7a, 4/07/202= 3 =C3=A0(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 a= bout deprecated glib2 declarations and causing build to fail with clang16:<= br> > >> ---
> >> /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: exp= anded from macro 'G_DEPRECATED'
> >> #define G_DEPRECATED __attribute__((__deprecated__))
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^ > >> mv -f .deps/bluefish.Tpo .deps/bluefish.Po
> >> bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_f= ull' is deprecated: Use 'g_thread_new' instead [-Wdeprecated-de= clarations]
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 g_thread_create_full(build_= bflang2scan_thread, NULL, 0, FALSE, FALSE, G_THREAD_PRIORITY_LOW, &gerr= or);
> >> ---
> >>
> >> Any help is welcome on finding out its cause.
> >>
> >> a related issue: https://github.com/PCSX2/pc= sx2/issues/3315
> >>
> >> Build log: https://pkg-status.freebsd.org/beefy17= /data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log<= /a>
> > The actual error is an incompatible callback function signature:<= br> > >
> > bftextview2_autocomp.c:432:2: error: incompatible function pointe= r types passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka = 9;int (struct _GtkLabel *, char *, void *)') to parameter of type '= GCallback' (aka 'void (*)(void)') [-Wincompatible-function-poin= ter-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: expan= ded 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: passi= ng argument to parameter 'c_handler' here
> > GCallback c_handler,
> > ^
> >
> > I have seen these more often with glib-based applications. In som= e 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 th= e
> > 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 Committ= er (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000a9911205ffaa69dd--