On Tue, Apr 7, 2020 at 2:06 PM Vijay Kumar Banerjee <vi...@rtems.org> wrote: > > > > On Wed, Apr 8, 2020 at 12:49 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Tue, Apr 7, 2020 at 12:03 PM Vijay Kumar Banerjee <vi...@rtems.org> wrote: >> > >> > >> > >> > On Tue, Apr 7, 2020 at 11:12 PM Joel Sherrill <j...@rtems.org> wrote: >> >> >> >> >> >> >> >> On Tue, Apr 7, 2020 at 12:35 PM Gedare Bloom <ged...@rtems.org> wrote: >> >>> >> >>> >> >>> I'm not sure what error this is fixing, is there a ticket open for the >> >>> warning? >> >> >> >> >> >> No idea on this. >> >>> >> >>> >> >>> Is there a fix for the warning besides squelching it? >> >> >> >> >> >> I think these are the warnings that are build failures on some hosts. <I >> >> think> >> > >> > >> > I get these errors on Fedora30: >> > >> > ``` >> > ../../glib-2.39.3/gio/gdbusauth.c: In function '_g_dbus_auth_run_server': >> > ../../glib-2.39.3/gio/gdbusauth.c:1297:11: error: '%s' directive argument >> > is null [-Werror=format-overflow=] >> > 1297 | debug_print ("SERVER: WaitingForBegin, read '%s'", line); >> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > ``` >> > The added patches fix this. >> > >> I see, this is a build error with newer gcc toolchains? > > Yes >> >> Is this only >> affecting qemu-couverture? > > yes, it's only affecting qemu-couverture >> >> What version of gcc is your host using? > > $>gcc --version > gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1) >> >> Can >> you try to find if there is a ticket open in glib or if this is fixed >> in newer version, so we can track for the upstream fix? >> > I found these patches from the bugzilla issue: > https://bugzilla.gnome.org/show_bug.cgi?id=761550 >
OK go ahead and push this. It would be better if qemu was updated or could use the new-enough version, but I understand. >> If newer versions of glib fix it, consider bumping the version? > > I'm getting these errors from glib-2.48.2 as well. >> >> Is >> qemu-couverture up-to-date? > > No, and it fails to build. There are issues in qemu-couverture as well. >> >> >> >> >>> >> >>> >> >>> How permanent is that gitlab? Should we just pluck these patches >> >>> ourselves? >> >> >> >> >> >> That's gnome.gitlab.org and per the link at >> >> https://www.gnome.org/gnome-3/source/, >> >> it appears to be the official GNOME git repository. I think I would trust >> >> it. >> >> >> >> --joel >> >> >> >>> >> >>> >> >>> On Tue, Apr 7, 2020, 7:59 AM Vijay Kumar Banerjee <vi...@rtems.org> >> >>> wrote: >> >>>> >> >>>> --- >> >>>> bare/config/devel/glib-2.39.3-1.cfg | 4 ++++ >> >>>> 1 file changed, 4 insertions(+) >> >>>> >> >>>> diff --git a/bare/config/devel/glib-2.39.3-1.cfg >> >>>> b/bare/config/devel/glib-2.39.3-1.cfg >> >>>> index 9ff7af5..bd5770a 100644 >> >>>> --- a/bare/config/devel/glib-2.39.3-1.cfg >> >>>> +++ b/bare/config/devel/glib-2.39.3-1.cfg >> >>>> @@ -14,6 +14,10 @@ >> >>>> >> >>>> %hash sha256 glib-%{glib_version}.tar.xz >> >>>> d9fa6c9aa645a5e688a3bb29013bb83801b19ee767d99e33ff52e004e1cc5fc8 >> >>>> >> >>>> +#Patch to supress string literal warning >> >>>> + >> >>>> +%patch add glib >> >>>> https://gitlab.gnome.org/GNOME/glib/commit/0817af40e8c74c721c30f6ef482b1f53d12044c7.patch >> >>>> +%patch add glib >> >>>> https://gitlab.gnome.org/GNOME/glib/commit/566e1d61a500267c7849ad0b2552feec9c9a29a6.patch >> >>>> # >> >>>> # The GLib build instructions. We use 2.x.x Release 1. >> >>>> # >> >>>> -- >> >>>> 2.21.1 >> >>>> >> >>>> _______________________________________________ >> >>>> devel mailing list >> >>>> devel@rtems.org >> >>>> http://lists.rtems.org/mailman/listinfo/devel >> >>> >> >>> _______________________________________________ >> >>> devel mailing list >> >>> devel@rtems.org >> >>> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel