Building desktop-file-utils-0.18 on an OS X box with glib-2.22.4 installed succeeds, but building 0.20 fails: checking for pkg-config... /sw/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for DESKTOP_FILE_UTILS... yes [...] CC install.o gcc -DHAVE_CONFIG_H -I. -I.. -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -DDATADIR="\"/sw/share\"" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/sw/include -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -c install.c install.c: In function 'main': install.c:943: warning: implicit declaration of function 'g_slist_free_full' install.c:943: warning: nested extern declaration of 'g_slist_free_full' [...] CCLD desktop-file-install Undefined symbols for architecture i386: "_g_slist_free_full", referenced from: _main in install.o ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status make[2]: *** [desktop-file-install] Error 1 g_slist is only available in glib as of 2.28 I think, whereas the autoconf test in configure.ac does not check for that: PKG_CHECK_MODULES(DESKTOP_FILE_UTILS, glib-2.0 >= 2.8.0) Either need to make that a stricter version requirement or adjust install.c to use more backward-portable functions.
It's just g_slist_free_full() that's missing (added in 2.28) rather than the whole g_slist_* API (a long-standing part of glib). That function is actually (as of glib-2.32.0) just a simple convenience function, implemented in gslist.c as: void g_slist_free_full (GSList *list, GDestroyNotify free_func) { g_slist_foreach (list, (GFunc) free_func, NULL); g_slist_free (list); } Pasting that into src/install.c as _g_slist_free_full and calling it instead of glib's actual g_slist_free_full at the end of install.c main() allows d-f-u 0.20 to build completely against glib-2.22.4
Created attachment 59344 [details] [review] Local implementation of g_slist_free_full to avoid requiring glib>2.28 I think maintaining compatibility with older glib is a better approach here since it's so trivial to accomplish. So here's the patch that we're using in Fink.
I committed a different fix, with GLIB_CHECK_VERSION. Just wondering: is it an issue to require glib 2.28?
I'm a downstream maintainer of the gnome package stack on OS X platforms, and glib >= 2.26 is blocked for us--the new (as of that point) gdbus is not implemented on darwin, so many other parts of the gtk/gnome stack might be blocked as well. That's why I'm interested in avoiding much newer glib than really necessary. No problem for me to patch around it obviously, and as long as there's the explicit test for >=2.28, from-source manual builders will know they have to do *something* to solve the problem.
That's good to know, thanks. For reference, as dfu is a tool that we want to have running on as many platforms as possible, I'm happy to make efforts in that direction if there are other issues in the future (not that I can think of future issues, but who knows).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.