In regard to: Re: problems building 1.1.24 (gettext), David Starks-Browning...:
>On Monday 21 Aug 00, [EMAIL PROTECTED] writes:
>> > In my case, this forces -lintl for Linux and Solaris too, but that
>> > didn't seem to cause any harm. (At least not yet...) It was
>> > sufficient to get gimp built on all 4 platforms.
>>
>> This shouldn't work on all systems. Normally glibc2 system don't have
>> a libintl and the linker will strike back if you still try to link
>> against it.
>
>Sure, but in the case of IRIX and OSF, configure found the gettext
>routines by linking against -lintl. If that works, it ought to set
>INTLLIBS accordingly. My hardcoding of -lintl wasn't meant to be a
>general solution. I just meant to demonstrate that configure should
>be setting this when it's required to find gettext routines. (Again, I
>don't know why it doesn't look in -lintl for dcgettext.)
I missed the beginning of this thread, but I know exactly what David
is talking about. It's a bug in the gettext configure routine. I've
reported it in various forums, including against various GNOME apps
via the GNOME bug tracker, in the gnu.utils.bugs newsgroup, and to
Ulrich directly, but I've never heard back from anyone. Since
all of the GNOME and gimp routines base their configure code for
finding and using gettext on the original `gettext.m4' that comes
with gettext, this bug has propagated to virtually every package that
uses gettext.
>> This issue is not easy to solve.
>
>You may be right about that. My personal suspicion is that the
>autoconf rules associated with gettext are broken. I suppose that's
>not your problem.
It is a problem with the autoconf rules. People with gettext in libc
don't see the problem, but it affects pretty much everyone else.
I've included the patch against gettext-0.10.35, that fixes the gettext.m4.
Note that this fixes the original source of the problem, but since the
faulty macro has propagated into so many packages (in some cases being
modified and having package-local versions of the macro), additional patches
and work are required to get things working for many packages.
In some cases, you can get a package to use the newer gettext configure
routines by re-running aclocal and then autoconf. This only works if the
package doesn't have a copy of gettext.m4, and if it's using the standard
AM_WITH_NLS, which is called by AM_GNU_GETTEXT (that's what you'll typically
see in configure.in). Many of the GNOME packages have their own slightly
different macro, AM_GNOME_WITH_NLS, which is called by AM_GNOME_GETTEXT.
If the package uses AM_GNOME_GETTEXT, you'll need to patch AM_GNOME_WITH_NLS
in its local copy of gnome-gettext.m4.
I have patches that should fix this problem for gtk+, gimp, and many of
the gnome packages. I've reported this in various places since October
of last year, but haven't had much luck getting people interested in fixing
the problem. Since gtk+, gimp, and many of the GNOME packages have become
better about honoring --disable-nls, that's the route I've been taking lately.
Tim
--
Tim Mooney [EMAIL PROTECTED]
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 21:33:02 1999
@@ -49,7 +49,16 @@
[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
+ dnl since we override the action-if-true clause,
+ dnl we must add -lintl to LIBS manually.
+ LIBS="$LIBS -lintl"
+ dnl autoconf would also define HAVE_LIBINTL for us
+ dnl if we had left the action-if-true clause blank.
+ dnl Since we do not really need this symbol, we will
+ dnl not define it ourselves.
+ dnl AC_DEFINE(HAVE_LIBINTL)
+ ],
gt_cv_func_gettext_libintl=no)],
gt_cv_func_gettext_libintl=no)])
fi
