I just submitted a (long-ish) bug report explaining a long-standing
gettext-related problem, but bugs.gnome.org yacked it back at me, so here
it is. The problem has been around forever, but I just noticed it again
because I tried (for the first time in a long time) to configure gimp without
using --disable-nls.
Tim
--
Tim Mooney mooney@xxxxxxxxxxxxxxxxxxxxxxxxx
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
---------- Forwarded message ----------
Date: 11 Dec 2000 23:31:07 -0000
From: MAILER-DAEMON@xxxxxxxxxxxxxxxxxxxxxxx
To: mooney@xxxxxxxxxxxxxxxxxxxxxxxxx
Subject: failure notice
Hi. This is the qmail-send program at tirania.nuclecu.unam.mx.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<submit@xxxxxxxxxxxxxx>:
/ Unknown ticket service address <submit@xxxxxxxxxxxxxx
Recognised addresses are:
/ General: Read # in Subject: Ticket # is NNNN:
/ request submit bugs NNNN NNNN-submit
control maintonly NNNN-maintonly
owner quiet NNNN-quiet
postmaster forwarded NNNN-forwarded
done close NNNN-done NNNN-close
submitter NNNN-submitter
/ (all @nic.tln.org.)
/ For instructions via the WWW see:
http://bugs.gnome.org/
http://bugs.gnome.org/Reporting.html
http://bugs.gnome.org/Developer.html
http://bugs.gnome.org/Access.html
Instructions are available from the TLN helpdesk staff
in the files:
doc/bug-reporting.txt
doc/bug-log-access.txt
doc/bug-maint-info.txt
/ For details of how to access ticket report logs by email:
send `request@xxxxxxxxxxxxxx' the word `help'
--- Below this line is a copy of the message.
Return-Path: <mooney@xxxxxxxxxxxxxxxxxxxxxxxxx>
Received: (qmail 1022 invoked from network); 11 Dec 2000 23:31:01 -0000
Received: from dogbert.cc.ndsu.nodak.edu (134.129.106.23)
by tirania.nuclecu.unam.mx with SMTP; 11 Dec 2000 23:31:01 -0000
Received: from localhost (mooney@localhost)
by dogbert.cc.ndsu.NoDak.edu (8.11.0/8.11.0) with ESMTP id eBBNUcM44662
for <submit@xxxxxxxxxxxxxx>; Mon, 11 Dec 2000 17:30:38 -0600 (CST)
Date: Mon, 11 Dec 2000 17:30:37 -0600 (CST)
From: Tim Mooney <mooney@xxxxxxxxxxxxxxxxxxxxxxxxx>
To: <submit@xxxxxxxxxxxxxx>
Subject: gimp-1.1.30: long-standing gettext problem on non-Linux systems.
Message-ID: <Pine.OSF.4.31.0012111612500.969-100000@xxxxxxxxxxxxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Package: gimp
Version: 1.1.30
Note: This problem affects all versions of gimp up through 1.1.30. The
issue I'm going to explain is what is being described in #34786, and possibly
elsewhere.
I'm reported the problem to gnu.util.bugs, on the gimp mailing list, against
several gnome packages (e.g. gnumeric 0.41), and elsewhere, but I've never
seen my patch incorporated or an alternate used. The problem is a bug in
gettext's gettext.m4 that has propagated into virtually every package that
uses it. It's especially troublesome for many of the GNOME packages,
because they use custom versions of the (buggy) macro in question.
On systems where bindtextdomain et. al are *not* in libc (i.e. they're
in libintl, part of gettext), a typical configure run *when GNU gettext
is installed* looks like this:
checking for stpcpy... no
checking for LC_MESSAGES... yes
checking whether NLS is requested... yes
checking whether included gettext is requested... no
checking for libintl.h... yes
checking for gettext in libc... no
checking for bindtextdomain in -lintl... yes
checking for gettext in libintl... checking for gettext in -lintl... yes
yes
checking for msgfmt... /local/gnu/bin/msgfmt
checking for dcgettext... no
checking for gmsgfmt... /local/gnu/bin/msgfmt
checking for xgettext... /local/gnu/bin/xgettext
checking for catalogs to be installed... fr sv ja it fi ko de hu nl pl ru no
cs
Note that although bindtextdomain in libintl is found, dcgettext is not.
Here's the explanation of the problem, that I sent directly to Ulrich Drepper
and have posted to multiple bug-related forums, since then.
------8<----------------------8<--------------------------------------
The problem is that in the situation where configure detects bindtextdomain and
gettext in -lintl, it defines HAVE_GETTEXT *but* it does *not* add `-lintl' to
LIBS. This means that `-lintl' will not be substituted into any Makefiles,
and subsequent links will fail.
Notice also that `gettext in libintl' is printed and answered with `yes' twice.
The code that checks for gettext in libintl and that prints out the message
twice is the following code, from AM_WITH_NLS in gettext.m4.
if test "$gt_cv_func_gettext_libc" != "yes"; then
AC_CHECK_LIB(intl, bindtextdomain,
[AC_CACHE_CHECK([for gettext in libintl],
gt_cv_func_gettext_libintl,
[AC_CHECK_LIB(intl, gettext,
gt_cv_func_gettext_libintl=yes,
gt_cv_func_gettext_libintl=no)],
gt_cv_func_gettext_libintl=no)])
fi
Because `action-if-found' *is* specified in both of the calls to AC_CHECK_LIB,
AC_CHECK_LIB is *not* automatically adding `-lintl' to LIBS and calling
AC_SUBST on that. It's also not automatically defining HAVE_LIBINTL.
Based on how deeply you're nesting AC_* calls, you're obviously better with
m4 than I am, so I'm not providing a patch.
I'm not sure how to fix the minor problem of the message being printed twice.
It's obviously coming from the AC_CACHE_CHECK followed by the AC_CHECK_LIB,
but I don't know how you would appropriately fix that -- I've done lots of
configure.in work but I haven't worked with cacheing much, so AC_CACHE_VAL
and AC_CACHE_CHECK are unfamiliar to me.
Regarding the more serious problem, I believe you could alleviate the problem
by either removing the `action-if-found' clause of either of the AC_CHECK_LIB
clauses above (which would probably hinder the cacheing) or you could add
something like
LIBS="$LIBS -lintl"
AC_DEFINE(HAVE_LIBINTL)
AC_SUBST(LIBS)
to the `action-if-found' clause of either of the AC_CHECK_LIB calls above.
Please let me know if you have questions/concerns/comments.
----------------8<---------------------8<------------------------------------
I subsequently produced a straight-forward patch to gettext.m4 for the
problem. It is at the end of this message. The GIMP's aclocal.m4 should
be regenerated after this patch has been applied, though the fix will be
lost by anyone that rebuilds aclocal.m4 on their own machine, assuming the
same patch isn't included in their gettext.m4.
I realize that this isn't really the gimp's problem, but anyone that has
gettext installed on a system that doesn't have bindtextdomain et. al in
libc is not going to be able to build the GIMP (and scores of other
packages) unless they --disable-nls.
Once this patch is applied, aclocal.m4 is rebuilt, configure is rebuilt,
and things are configured, most of the GIMP will build successfully with
gettext support. There is still a problem with the perl plug-in after
this fix is made, though. I'll describe that in a later bug report,
since it's only superficially related (the perl plug-in can't find -lintl
because GIMP's LDFLAGS are in _LDFLAGS for the perl Makefile, and that
isn't used in the link).
Tim
--
Tim Mooney mooney@xxxxxxxxxxxxxxxxxxxxxxxxx
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
diff -ur gettext-0.10.35.orig/m4/gettext.m4 gettext-0.10.35/m4/gettext.m4
--- gettext-0.10.35.orig/m4/gettext.m4 Fri May 1 00:45:20 1998
+++ gettext-0.10.35/m4/gettext.m4 Mon Oct 25 00:21:04 1999
@@ -49,7 +49,10 @@
[AC_CACHE_CHECK([for gettext in libintl],
gt_cv_func_gettext_libintl,
[AC_CHECK_LIB(intl, gettext,
- gt_cv_func_gettext_libintl=yes,
+ [ gt_cv_func_gettext_libintl=yes
+ LIBS="$LIBS -lintl"
+ AC_DEFINE(HAVE_LIBINTL)
+ ],
gt_cv_func_gettext_libintl=no)],
gt_cv_func_gettext_libintl=no)])
fi
