In regard to: Re: problems building 1.1.24 (gettext), David Starks-Browning...: >On Monday 21 Aug 00, egger@xxxxxxx 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 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 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
