From nobody Tue Jul 04 14:42:34 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 4QwQWB0JQQz4lbRZ for ; Tue, 4 Jul 2023 14:42:46 +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 4QwQWB084pz3jgN; Tue, 4 Jul 2023 14:42:46 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1688481766; 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=35/8nz1T821nKhH+88fC8kAodCrM5mp3NsIb0ZU3eMg=; b=JaklOuorUBW3EEpTtD2qo8whqcxMyd64D/FDHcEOnOzyjQ78LOrjIogxDCwJP8IwLr9LlV 7Tg0uV2t4fzkg3GW2bmXmPSMrX50N454GmeaHc6RFAd7HQRbBDh8lzrRUnMGr4sbAzFHxu 0o2tXgvAsWEXaseHdtD+ErhBeGd7FvAx1NvXo8TZfprFQFRivElEy6etheZTPTAUtfYxYN rO0x38i5hqRQAXHWh84csLEZPfyM6bGIoOe+lYz0bmxZdZYk0HoWv6L/gymuB0Mmm1JIej MJ5+6LUROBRvce4NWHAXYm/y6WZSoTPNje7+pFlis67BKgIP1vo9htrqNsDr7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1688481766; 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=35/8nz1T821nKhH+88fC8kAodCrM5mp3NsIb0ZU3eMg=; b=vkXGJlJoGcJ3kLAPQCHBQ+shHmcOnrPZImKwDdBo892IV9G8966W/vxueExVGPvIfVEl11 zMTQ6hO9OLMSVNOuYSHdE/u4BPimAuJk4FL6NL1XLSwAvMBV4LCJYpj1xyfvUokE3bCIvz 0KI5PmLP2brzzuYZ+MzccSpLHQLwAbEoEyFpuuCWerAvJkC2iwg78uS1ekb6hyLglP8Qor HU3b4kvvIHZtQ1j8XzcOCdPkyma8CS+sU0F7iNBcisy4KQw0ttvLSztE1lqwi6uKLTlSpH OHYIMn1ShB2z5VfmF3oTY6nau9eWlYEtowzwM8t2wBKJPGFFlpodcTT7fW4H6Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1688481766; a=rsa-sha256; cv=none; b=X2l/nRNoI3DjkjUjGE1CyiZU23xW/nPauGPKbgyRo2UZRjMWsTM2QJhPqbqst+QnyAMS7O m3oCic3Q36vPXyIhecbacBUc4KVOGjrGyntYwvIRxyW3uhSJ8vrr3EPBACon/qoK6aGody fwVZqquSEXLWshCE3kyJgeWs8Y0/sv6mPHtDY3s4Vf1kDdcRIYzgWBrtj1xLXESxDi8X9R ZYlp3NgtrsMVZ/ohw7eDpiRvbcMkjBlZwDNNDqvPibhg+pJmuCpdcDqtpEVpvnp3Gmy31q ZyjWe9emlsZ6CcJ8tVQSyuDWfDslUJBdIEdJ7B2Z1gvOsJDmc7u84n7FZf1BDA== Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 4QwQW96CZZzJf5; Tue, 4 Jul 2023 14:42:45 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-40355c95677so13538491cf.2; Tue, 04 Jul 2023 07:42:45 -0700 (PDT) X-Gm-Message-State: AC+VfDz3B0J9F30PLKDnY92cz+gEWI2jYFTN1SQwFC8tcPkzHOb5O30x gxZ7i1ioOMA6j9lzFBHnuw7C6OsoKr2KNoYsnR0= X-Google-Smtp-Source: ACHHUZ6OECSzwKdK50oPtU5WktWcXFBa0H6DZnPnW0m2Gk8gHjbAqy3CoPrS4bmr9yQk0G+fBDg77+hYGviT83+NmK0= X-Received: by 2002:ac8:5e4a:0:b0:3fd:da36:3e97 with SMTP id i10-20020ac85e4a000000b003fdda363e97mr13364107qtx.34.1688481765317; Tue, 04 Jul 2023 07:42:45 -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: <22F61A7B-3566-4761-8D7A-DC78B9CF20E6@FreeBSD.org> From: Nuno Teixeira Date: Tue, 4 Jul 2023 15:42:34 +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="000000000000d4e23b05ffaa4b3b" X-ThisMailContainsUnwantedMimeParts: N --000000000000d4e23b05ffaa4b3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 an= d 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(acw= in_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/pf46bd2c584= 25_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 (struc= t > _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka 'voi= d > (*)(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) > > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000d4e23b05ffaa4b3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=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)
--000000000000d4e23b05ffaa4b3b--