Relying on glib to publish gettext linker flags

[Daniel Macks <dmacks netspace org>]

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.

dan

-- 
Daniel Macks
dmacks netspace org
http://www.netspace.org/~dmacks