GNOME Bugzilla – Bug 85217
GNU gettext dependency
Last modified: 2011-02-18 15:57:04 UTC
glib does two wrong things to prevent using system's gettext even it has required functionarity to build glib and the rests of GNOME2 modules. 1) autogen.sh does 'xgettext --version' to check The --version check is too GNU-ish. LI18NUX2000 Ammendant does not require --version support in xgettext. 2) m4macros/glib-gettext.m4 uses "_nl_msg_cat_cntr" This is wrong too - even in the old version of GNU gettext < 0.10.36, _nl_msg_cat_cntr was defined, but bind_text_domain_cdeoset was not included in these old version. glib-gettext-m4 macro should do better check and only actually required gettext functionality should be checked - but not --version nor _nl_msg_cat_cntr.
GLib and GTK+ aren't supposed to require bind_textdomain_codeset() - bug 70627 is the master bug for that debate. I'm not going to get to any glib-gettext.m4 hacking for 2.0.x, certainly. A patch would help get this into 2.2.
Calling bind_textdomain_codeset() with UTF-8 is a hard requirement when all locale's .po files are encoded in UTF-8. If you agree to this, checking the bind_textdomain_codeset function and reject the old gettext versions will be a thing to do, I think. How about replacing dcgettext check at m4macros with bind_textdomain_codeset's?
Note: the GLib policy hsa been. Call bind_textdomain_codeset() if it is present. This works perfectly if your message catalog files are UTF-8, as they are for GLib and GTK+. If you don't have bind_textdomain_codeset(), then the files wont' be translated. I'm working on a looking at a rewrite of the messages, and the check for "_nl_msg_cat_cntr" is not required; what it is there to check is the format of the catalog files. If the catalog files are GNU format files, then they will have the .gmo suffix in the po/ directory. Does the new Solaris gettext use GNU format or the traditional Solaris format? If it uses the traditional format but we use CATOBJEXT=.gmo, then the .mo files won't be properly regenerated in the correct format when installing from a tarball.
A autoconf check to check for an "appropriate version" of xgettext is going to be fairly complicated. What it probably woudl have to do is actually write out a test C file with translatable strings in it, and then run xgettext with the arguments that po/Makefile.in.in uses. The "damage" is simply that you need GNU xgettext to update the po files (say, when making dist, or working on translations. This doesn't seem urgent to me. I'd take a patch to do this for a future version, but I don't want to do it at the moment, especially since I don't have anything but GNU gettext to test on. _nl_msg_cat_cntr as mentioned above isn't an issue.
(This is from memory, my Solaris machines are at work... This comment isn't necessarily 100% accurate, the issues are rather complex, but I definitely had to dig into this at one time, and found out something like the following.) One interesting thing with Solaris (7, at least) and the Forte C compiler is that the compiler (don't remember if it was the previous version (5) or the current (6u2)) insists on adding -lintl to the linker command line even if the original c89 or cc command line contained no such thing, even if Solaris has gettext() and friends also in libc. But no bind_textdomain_codeset() in Solaris, so one tends to want GNU libintl. And to further complicate matters, if you build GNU libintl normally, it gets called libintl.so.1. The same name as the Solaris libintl in /usr/lib... This causes strange errors. I ended up building the GNU libintl as libintl.so.2, so at least there is no confusion in which is referred to from an executable.
I'd get back to this old issue for 2.2 and HEAD. On all the Solaris versions where Sun supports GNOME2 (actually, it is Solaris 8 FCS and later), native gettext supports both GNU format and traditional format catalogs, so checking the catalog formats and then decide to go with CATOBJECT=.gmo or .mo, and datadir=share or datadir=lib should work. Will you please send me this patch, then I'll test it out.
By "I'd take a patch to do this for a future version", I meant "if someone wants to make up a patch, I'd accept it". Everything I was working on has been in CVS since before 2.2.0. I don't have any idea of how to do things like "check to see if gettext supports .gmo files" in a way that will work for both GNU gettext and Solaris, so I'm not going to be able to work on changes here myself.
I'll try to make up a patch, but I'll only be able to make one to save Solaris gettext. Is it okay to do something like [case $host in *-*-solaris*) // do for Solaris ?
Attaching a new patch, should have zero impact on any other systems than Solaris. Fixing this is crtical on Solaris. Currently, there is no message translations if apps using glib-getext.m4 are built without GNU gettext. [Sun shipped own patch on GNOME2.0]
Created attachment 17206 [details] [review] proposed patch to add solaris specific check.
I don't understand why you don't get message translations, if you say that traditional format message catalogs are supported as well. But your patch looks fine; it might be nice to indent it a bit more so that the indents follow the block structure. Also, unless bind_textdomain_codeset is a macro, you could probably just use AC_CHECK_FUNC(bind_textdomain_codeset, [action-if-found], [action-if-not-found]) rather than AC_TRY_LINK and save a bit of code. But those are minor details.
hmm, seems I was having other troubles (some incorrect local patch or something) when I saw message translations broken. I cannot reproduce it now. Anyway, I'm applying a patch to both branches, incorportaing your suggestions.
Fri Jun 6 10:24:23 2003 Hidetoshi Tajima <hidetoshi.tajima@sun.com> * m4macros/glib-gettext.m4: Test for Solaris native gettext in libc, seeing if it supports GNU catalog format (#85217).
Created attachment 17243 [details] [review] actual patch to commit.