GNOME Bugzilla – Bug 534319
GLib's .pc files could use Libs.private
Last modified: 2008-05-25 10:27:29 UTC
I think it would be more appropriate to have the INTLLIBS and ICONV_LIBS on a Libs.private line in glib-2.0.pc instead of the Libs line. The same for G_MODULE_LIBS in gmodule-2.0.pc. G_THREAD_LIBS probably should stay on the Libs line though, as on some platforms all software that links to some library (i.e. libgthread) that uses threads might also need to link with the platform's thread-aware version of C library, or something like that. In glib-2.0-uninstalled.pc, INTLLIBS and ICONV_LIBS presumably can be dropped completely, as it specifies the .la file anyway, and any required dependencies will be handled through that, won't they?
Created attachment 111328 [details] [review] Suggested patch I admit this change might be risky, it might break something on some odd platform. And it will break build of software that has relied on implicitly being linked with INTLLIBS and haven't bothered specifying INTLLIBS in its Makefiles. (This will of course only be seen on platforms where INTLLIBS is non-empty.) The current situation isn't broken as such... just slighly annoying. So feel free to resolve as WONTFIX if you think that is safest.
gettext() and other libintl stuff is supposed to be usable without additional libraries when you link against GLib, so INTLLIBS isn't Libs.private iconv is wrapped within glib, so should be OK to make private.
Created attachment 111337 [details] [review] Updated patch OK. Like this then?
Patch committed to trunk (only).