There are several issues here: 1) geoclue uses a bundled geocode-glib. I know there was some code sharing between the two, but we should considter unbundling and using the system geocode-glib. 2) geoclue's codebase adopted through the following commit https://cgit.freedesktop.org/geoclue/commit/?id=cd1f4dd55af7c39e6d0607cc9020717fb98e2eea the following code from geocode-glib: https://git.gnome.org/browse/geocode-glib/commit/?id=f0f85d8d01c64c61dfef3d00af5b9e629e336213 This commit tries to guard against using _NL_ADDRESS_POSTAL_FMT on non-glibc systems using #ifdef __GLIBC__ This is fine for musl systems which does not define any such macros, but not for uclibc where we need to have #if defined(__GLIBC__) && !defined(__UCLIBC__) In the uclibc world this reads as a function which is found in glibc but not in uclibc. Since uclibc and glibc share much codebase, it is important to write it this way.
Created attachment 428132 [details, diff] geoclue-2.4.1-fix-uclibc.patch I will try to convince upstream of this fix. In the mean time, can we have epatch_user in geoclue so that it doesn't block us.
The geoclue people wanted me to bounce this to geocode-glib: https://bugzilla.gnome.org/show_bug.cgi?id=764021
(In reply to Anthony Basile from comment #2) > The geoclue people wanted me to bounce this to geocode-glib: > > https://bugzilla.gnome.org/show_bug.cgi?id=764021 this was accepted into geocode-glib and now the geoclue people need to merge it into their project https://git.gnome.org/browse/geocode-glib/commit/?id=3ce317a218c255b8a8025f8f2a6010ce500dc0ee
@gnome team, all upstreams have accepted this. can i go ahead and back port it. its not something that could possibly affect glibc systems so a back port to stable is save.
Go ahead please :)
(In reply to Pacho Ramos from comment #5) > Go ahead please :) both geoclue and geocode-glib are fixed. thanks. the patches should be droppable on the next bump.