After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 119171 - glib-gettext.m4 DATADIRNAME and dcgettext checks
glib-gettext.m4 DATADIRNAME and dcgettext checks
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.2.x
Other OSF/1
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2003-08-05 14:48 UTC by Tim Mooney
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim Mooney 2003-08-05 14:48:29 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).
Comment 1 Owen Taylor 2003-08-05 15:09:22 UTC
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.

Comment 2 Tim Mooney 2003-08-05 16:40:19 UTC
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?
Comment 3 Owen Taylor 2003-08-07 19:10:56 UTC
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)
Comment 4 Tim Mooney 2003-08-07 19:27:23 UTC
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.
Comment 5 James Henstridge 2003-08-19 11:27:35 UTC
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).
Comment 6 Owen Taylor 2003-08-19 13:55:59 UTC
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)