Created attachment 56712 [details] [review] proposed patch g_win32_get_package_installation_subdirectory() has been deprecated since GLib 2.18 and in recent (2.31) GLib versions disabled entirely by default. This patch replaces usage of that function by g_win32_get_package_installation_directory_of_module() and g_build_filename(). g_win32_get_package_installation_directory_of_module is supported since GLib 2.16. Perhaps the minimal GLib version in the configure.ac PKG_CHECK macro should be changed accordingly?
Comment on attachment 56712 [details] [review] proposed patch Review of attachment 56712 [details] [review]: ----------------------------------------------------------------- Looks like this introduces a leak, but we already were leaking from g_win32_get_package_installation_directory, so I guess this isn't really much worse. Can you test with the change suggested below? ::: pkg.h.old @@ +27,4 @@ > /* It's OK to leak this */ > #undef PKG_CONFIG_PC_PATH > #define PKG_CONFIG_PC_PATH \ > + g_strconcat (g_build_filename (g_win32_get_package_installation_directory_of_module (NULL), "lib/pkgconfig"), \ The documentation on g_build_filename says the argument list must end in NULL, so it looks like we need a NULL after "lib/pkgconfig". http://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-build-filename Also, since we're using g_build_filename, we might as well split "lib" and "pkgconfig" into separate args so we ensure the appropriate directory separator is used. Same comments apply below.
This one got fixed a little differently in commit 7ac6f32 and got some confirmation to work on msys.
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.