Hi, On Thu, Feb 11, 2010 at 6:59 PM, Daniel Macks <[email protected]> wrote: > Coming here for wider input from gnome bugzilla Bug #606977 (and now > I'm rethinking the much older Bug #500137), which seems to center on > the line in glib-2.0.pc.in: > > Libs: -L${libdir} -lglib-2.0 @INTLLIBS@ > > The @INTLLIBS@ AC/AM variable is a standard one set by the gettext > autoconf chunks. It may be blank, or contain -lintl, or whatever else > was determined to be needed (or explicitly passed by user per normal > autoconf methods) to link against the gettext library (libintl) at the > time glib was built. Gettext does not supply a .pc file, so this seems > to be a work-around for a glib-2.0.pc entry like "Requires: gettext", > which would let the gettext installed when glib's .pc is read publish > its own linker flags. Here though, we have a different behavior: > glib's .pc is publishing hardcoded flags of an external dependency lib > based on when glib was built. > > My question is whether other packages should rely on the glib-2.0.pc > Libs containing the flags necessary to link against gettext, or if > instead these packages should be dealing with gettext linker flags > directly themselves. Packages that use gettext have the same standard > autoconf chunk as glib itself, and therefore access to the INTLLIBS > variable as determined at their build time (rather than at the build > time of the glib dependency). > > I have two problems with the current glib-2.0.pc.in setup: > > 1. It has INTLLIBS at the time glib was built, which may not still be > correct when building packages that depend on glib if gettext is > changed or if user wants to use a different one. For example, I > install a newer version in a private place, but this entry in the > global .pc causes the old one to be linked. That is, either "and also > the old one" if a package does pass its own INTLLIBS, or "only the old > one even if configure correctly detects or is passed the way to use > the new one" if not. > > 2. It forces every package that uses glib to link directly to > libgettext, even those that don't use it directly. That's a bunch of > ld and dyld overhead for no gain. Even -dead_strip or other dyld link > reduction tricks are only after-the-fact: I still need to have the > build-time gettext stuff (for example the "-dev" package, in > debian-speak) and then waste time unlinking against it. And if the > libintl I use (in a package that respects INTLLIBS) is not the same > one that was used, I wind up with a single lib possibly linking > against multiple SONAMES that supply the same symbols. That feels like > a recipe for problems. And linker noise (multiply-defined symbols), > which makes packages fail -Werror through no fault of their own. The > past several stable branches of gtk+ have defaulted to *not* > publishing un-necessary linker flags, instead requiring dependant > packages to determine and use whatever they actually need for > themselves. > > Gettext does not appear to be part of the external API of any part of > the actual glib library suite itself. The only public place it appears > anywhere public is in the the glib/gi18n*.h macro files. Those only > seem to be loaded they are #included explicitly/directly (i.e., not > part of the normal glib.h set). Those headers clearly document that > they are convenience macros around gettext functions. If one uses the > gettext macros supplied by glib, one has to manually include them, one > also has to use other gettext functions directly (bindtextdomain() or > simiar), and also add autoconf pieces. Therefore, it seems clear to me > that these are not intended to suggest that the actual work is handled > by glib or nor to hide the fact that it's still the gettext lib (with > all its own requirements for use) being invoked. Lastly, both the > library-supplied gettext.m4 and glib's glib-gettext.m4 public ac > macros document that they set INTLLIBS to contain the appropriate > linker flags, so users could/would/should expect that that variable is > overrideable as usual in ./configure and/or make. > > As precedent for what I consider the correct way (packages that use > the glib/gi18n*.h convenience macros but then also use their own > configure INTLLIBS when linking), gtk+ configure.in pushes INTLLIBS > into LIBS for many years, gconf passes it in Makefile.am, and atk just > accepted (Bug #606888) my rationale and patched a Makefile.am to pass > it. > > This is a real issue for me on OS X, since gettext is not in my system > lib itself nor is the external lib supplied by my os vendor. So I have > several third-party-supplied versions and copies of it and also my > user-land for testing. It's also not sufficient to have glib link > against libintl and then other packages just link against glib. > Darwin's linker does not allow indirect symbol references. I really > need clean control over how/when/where gettext gets linked. > > I'd love to get this resolved so I know whether to bother filing bugs > when I find "uses gettext but doesn't specify direct link against it" > and if there is a consensus on how other packages should handle it.
Did you ever manage to solve this issue? I quite often cross-compile GLib to ARM, and sometimes windows, and the gettext dependency has always been annoying, so I wrote a patch to disable it completely, although I haven't managed to finish it through. -- Felipe Contreras _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
