GNOME Bugzilla – Bug 119171
glib-gettext.m4 DATADIRNAME and dcgettext checks
Last modified: 2004-12-22 21:47:04 UTC
glib-gettext.m4 from glib 2.2.2 and earlier seems to have a couple problems. - minor (but annoying): For systems that don't have GNU gettext in libc, there's a bit of logic to try figure out what directory the `locale' dir should be under -- share or lib. All recent versions of GNU gettext *always* use share, though, so glib-gettext.m4 frequently gets it wrong, in the sense that it installs locale files under a different directory than the rest of the locale files are installed. Specifically, DATADIRNAME is always share with modern gettext, but glib-gettext.m4 often chooses lib instead. - Even when all the GNU gettext commands are found and libintl is found, the check for `dcgettext' fails. This happens because `-lintl' is no longer part of LIBS -- LIBS is reset after the checks above it succeed (or fail).
For the first problem, I think you'll need to debug the problem, there isn't enough information in what you provide to give any indication of why the current checks aren't working for you. Note that we *do not* require modern GNU gettext currently, so we cannot simply remove the checks.
My apologies for not being more explicit. Working from glib-gettext.m4 that is part of glib-2.2.2: - On line 155 of that version of that file is a section of code that begins (indenting is probably screwed up from cut-n-paste): if test "$gt_cv_func_dgettext_libintl" = "yes" ; then glib_save_LIBS="$LIBS" LIBS="$LIBS -lintl $libintl_extra_libs" unset ac_cv_func_bind_textdomain_codeset AC_CHECK_FUNCS(bind_textdomain_codeset) LIBS="$glib_save_LIBS" Prior checks have already established whether or not libintl is available, these checks see if bind_textdomain_codeset is available when that library (and any possible dependencies, e.g. libiconv) is part of LIBS. Notice that whether or not the check for bind_textdomain_codeset succeeds, LIBS is reset to *NOT* include -lintl and its dependencies. A few lines farther down, we have the code: if test "$gt_cv_func_dgettext_libintl" = "yes"; then INTLLIBS="-lintl $libintl_extra_libs" fi INTLLIBS is substituted into the various Makefiles in the case where the cache value is yes, so that whenever we link we add -lintl and its dependencies, since that's where this particular platform has its GNU gettext routines. The problem is, at least two subsequent checks: AC_CHECK_FUNCS(dcgettext) (on line 187) and AC_TRY_LINK(, [extern int _nl_msg_cat_cntr; return _nl_msg_cat_cntr], (on line 191) will both now fail, even though the checks earlier found libintl, determined it has what we need, and set INTLLIBS. These checks fail because `-lintl' and its dependencies were removed from LIBS when it was reset by LIBS="$glib_save_LIBS" on line 160. Now, because the AC_TRY_LINK(, [extern int _nl_msg_cat_cntr; return _nl_msg_cat_cntr], fails (because -lintl isn't part of LIBS), the "action-if-fail" part of the AC_TRY_LINK is executed. That section of code looks like this: [case $host in *-*-solaris*) dnl On Solaris, if bind_textdomain_codeset is in libc, dnl GNU format message catalog is always supported, dnl since both are added to the libc all together. dnl Hence, we'd like to go with DATADIRNAME=share and dnl and CATOBJEXT=.gmo in this case. AC_CHECK_FUNC(bind_textdomain_codeset, [CATOBJEXT=.gmo DATADIRNAME=share], [CATOBJEXT=.mo DATADIRNAME=lib]) ;; *) CATOBJEXT=.mo DATADIRNAME=lib ;; esac]) For hosts other than Solaris, the case statement takes the default, and DATADIRNAME is set to lib and CATOBJEXT is set to .mo. I'm positing that DATADIRNAME should always be `share', in all cases, but the only reason things are falling through to the default case is because the AC_TRY_LINK failed. If that had succeeded, as it would have if `-lintl' hadn't been prematurely removed from LIBS, the "action-if-true" clause of the AC_TRY_LINK would have been executed, and DATADIRNAME would have been set to `share'. Have I clearly illustrated what the problem is, or am I still doing a poor job of describing the problem?
OK, I didn't realize you were saying that they were related. Thu Aug 7 15:01:09 2003 Owen Taylor <otaylor@redhat.com> * m4macros/glib-gettext.m4: Set $LIBS to include -lintl when checking for dcgettext and _nl_msg_cat_cntr. (Tim Mooney, #119171)
You didn't realize I was saying the two issues were related because I was doing a very poor job of explaining it. Thanks for the fix. I will test with the next released version of glib, and mark as VERIFIED.
Owen: there is a problem with the patch you applied to glib-gettext.m4. If the system doesn't have a libintl.so, the check for _nl_msg_cat_cntr() fails. It looks like the following line which you added just above the check is the problem: LIBS="$LIBS -lintl $libintl_extra_libs" it should probably look like this: LIBS="$LIBS $INTLLIBS" This will include -lintl if it was previously determined that -lintl was needed. From conversations on IRC, this is causing some actual problems for people. The gettext package on RH9 does not appear to have a libintl.so in it. Since the contents of glib-gettext.m4 gets included in the configure scripts of many released tarballs, getting this fixed is quite important for the Gnome 2.4 release process (we will need to get new tarballs out and tested after the fix is applied).
Tue Aug 19 09:42:06 2003 Owen Taylor <otaylor@redhat.com> * m4macros/glib-gettext.m4: Add $INTLLIBS to $LIBS temporarily, not -lintl. (Problem with fix for #119171, pointed out by James Henstridge)