[1.15.7 and 1.15.8] fails to build on i386: passing argument 1 of 'gmtime_r' from incompatible pointer type

[paulgevers]

Recently liferea started to fail to build from source in Debian on i386 [1]. I suspect this is related to default changes in gcc (we're now using gcc-14) and I think I can work around this for now by preventing that warning to be treated as an error, but I'd like to let you know.

[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/liferea.html

gcc -DHAVE_CONFIG_H -I. -I../..  -DPACKAGE_DATA_DIR=\""/usr/share"\" -DPACKAGE_LIB_DIR=\""/usr/lib/i386-linux-gnu/liferea"\" -DPACKAGE_LOCALE_DIR=\""/usr/share/locale"\" -DBIN_DIR=\""/usr/bin"\" -I../../src -I../.. -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/i386-linux-gnu -I/usr/include/webp -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -I/usr/include/libxml2 -I/usr/include/libsoup-3.0 -I/usr/include/webkitgtk-4.1 -I/usr/include/json-glib-1.0 -I/usr/include/gobject-introspection-1.0 -I/usr/include/gsettings-desktop-schemas -I/usr/include/libpeas-1.0 -pthread  -DHAVE_G_MEMDUP2 -DHAVE_G_TIME_ZONE_NEW_IDENTIFIER -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 -pthread  -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/liferea-1.15.7=. -fstack-protector-strong -Wformat -Werror=format-security -c -o ../db.o ../db.c
../date.c: In function 'date_format_rfc822_en_gmt':
../date.c:485:19: error: passing argument 1 of 'gmtime_r' from incompatible pointer type [-Wincompatible-pointer-types]
  485 |         gmtime_r (&datetime, &dt);
      |                   ^~~~~~~~~
      |                   |
      |                   gint64 * {aka long long int *}
In file included from /usr/include/glib-2.0/glib/gtypes.h:41,
                 from /usr/include/glib-2.0/glib/galloca.h:34,
                 from /usr/include/glib-2.0/glib.h:32,
                 from ../date.h:24,
                 from ../date.c:35:
/usr/include/time.h:154:54: note: expected 'const time_t * restrict' {aka 'const long int * restrict'} but argument is of type 'gint64 *' {aka 'long long int *'}
  154 | extern struct tm *gmtime_r (const time_t *__restrict __timer,
      |                             ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
make[5]: *** [Makefile:582: ../date.o] Error 1

[lwindolf]

The date conversion is quite old code mixing Unix functions with Glib datetime. The right way is probably to do everything in glib.

The code line is from the RFC 822 conversion for which Glib does not have support (it only has ISO8601 support) as far as I know.

I think I should do some research how other Glib base projects do the RFC822 handling.

[paulgevers]

For your info, I successfully worked around the issue on i386 in Debian. If you give this low prio, or even wontfix prio, I can understand. i386 in Debian is moving towards an architecture to support running legacy code. Eventually dropping liferea from i386 in Debian wouldn't be that bad.

[nE0sIghT]

FYI this was reported in Gentoo also (https://bugs.gentoo.org/941973)

[yaneti]

FWIW its not reported for Fedora because we stopped building liferea for i686 around January, which was prompted by this issue... but that was just the trigger. The main reason is that it increasingly doesn't make sense to build internet facing GUI applications using a browser engine for i686.

[nE0sIghT]

I think I should do some research how other Glib base projects do the RFC822 handling

Maybe something like this? nE0sIghT@98decfb

I not tested this patch, just compile-tested on amd64