Re: Relying on glib to publish gettext linker flags

[Felipe Contreras <felipe contreras gmail com>]

Hi,

On Thu, Feb 11, 2010 at 6:59 PM, Daniel Macks <dmacks netspace org> 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