GNOME Bugzilla – Bug 617004
Build with "--disable-nls" fails under MinGW/Win32
Last modified: 2010-05-20 22:43:06 UTC
Created attachment 159730 [details] [review] remove the need for LC_MESSAGES When Glib is compiled under MinGW without Gettext (--disable-nls), the LC_MESSAGES symbol is not defined. The build thus fails with: gsettings.c: In function 'g_settings_get_value': gsettings.c:792: error: 'LC_MESSAGES' undeclared (first use in this function) One could work around that issue by using "#ifdef HAVE_LC_MESSAGES". However, it is also possible to change the affected code in a way that it doesn't need LC_MESSAGES in the first place. The attached patch does exactly that. It works because dgettext() uses the LC_MESSAGES locale facet.
The error also occurs on Unix systems when building with "--disable-nls".
I wonder if it makes sense at all to call gettext() if NLS is disabled. Maybe could just wrap the whole thing in an NLS ifdef.
The unconditional #include <locale.h> at the top of gsettings.c gets us LC_MESSAGES even if --disable-nls.
No, "#include <locale.h>" is only guaranteed to provide LC_TYPE. Some systems also provide LC_MESSAGES, but some systems don't (such as MinGW). Also, glib currently ignores "--disable-nls". So the bug isn't really triggered by that option. It is triggered when Gettext isn't found on the system. Nevertheless an explicit "--disable-nls" switch would be very nice. Finally, note that there already _is_ some kind of NLS ifdef. You'll find it in "glib/glibintl.h" where it provides dummy macros for dcgettext() etc. in case of a missing Gettext. My patch simply builds on that feature, and just tries to avoid the LC_MESSAGES symbol.
LC_MESSAGES comes from POSIX, not ANSI/ISO C. There is no LC_MESSAGES in the "standard" MinGW or MSVC headers. C_MESSAGES has no meaning in the Windows C library which doesn't have any <libintl.h>, gettext(), etc. It's GNU gettext that defines LC_MESSAGES in its <libintl.h> (and then accepts and uses that value in its code). So if you use LC_MESSAGES in the code, you must include <libintl.h>. Sorry. If Volker's patch introduces no misbehaviour, I'd say, go for it. Personally I don't think building GLib with localisation disabled is a good idea, especially not if you build it for distribution to others (as I think Volker is). Isn't it rude to declare that no users of the binaries you distribute can need localisation features in GLib? On the other hand, I do recognize that when bundling GLib (and/or the GTK+ stack even) with some application that isn't localised itself, it makes little sense to provide localisation in the libraries. That's why I compile and link the packages I distribute against "proxy-libintl", which loads the libintl library lazily at run-time, and if it isn't present, falls back gracefully to no localisation.
(And when I say "GNU gettext" above, I guess I mean "GNU or some other implementation of <libintl.h>, gettext() etc".)
(In reply to comment #5) > Personally I don't think building GLib with localisation disabled is a good > idea, especially not if you build it for distribution to others (as I think > Volker is). I think this needs some clarification. The finally produced win32-glib does have support for Gettext, and I fully agree with you in that regard. However, in order to cross-compile GLib, we need to work around a fundamental flaw in GLib: It builds the code generators (glib-genmarshal, etc.) with the cross-compiler rather than the native compiler. So before cross compiling, we need a separate native build of GLib. That build is minimal, just enough to produce the code generators. Those are then provided to the cross build. It is this native build that causes trouble on some systems where no Gettext is installed, but I don't think we should require Gettext just to build some code generators. Indeed, if GLib cross-compiled properly, I would not need to build a non-NLS variant. I also thought about fixing the issue directly in GLib, but this is highly non-trivial, because the code generators aren't stand-anlone programs. They make use of GLib themselves (WTF?!). So in order to build them natively, one would need to build big parts of GLib twice - natively and cross. Or, one would need rewrite the code generators to be independent of GLib. I have neither the time nor the motivation fix that mess, which is why I stick with the two-stage build for now. And that is why I need to be able to build a temporary GLib without external requirements such as Gettext.
Created attachment 161485 [details] [review] Make GLib's dependency on Gettext optional I attached my second attempt to make Glib a bit more independent from Gettext. We use this patch in Mingw-cross-env and it works flawlessly. Note that the patch doesn't eliminate the need for Gettext completely. However, it fixes enough issues to enable the build of the GLib/GObject code generators without any Gettext requirements. This enables the two-phase cross build as described in my previous comment. The patch does _not_ affect any NLS-enabled build. Would it make any sense for me to work further on that patch, such that GLib can build _completely_ without Gettext? Or, asked in a different way: Is there any interest of the GLib project in making its Gettext dependency optional? If so, I'd put more work into the patch. Otherwise, I'd keep it that way. Greets, Volker
hi Volker the configure.in changes you're suggesting are definitely out of scope for this bug. For now, we're going to take your suggestion about removing LC_MESSAGES and using dgettext instead (although we will have some other changes to make sure that works out properly if NLS is disabled). It may be appropriate to open another bug about the more general issue, but I'm not sure that there is a particularly high level of interest in no-gettext glib.
Created attachment 161503 [details] [review] Add g_dc[p]gettext Bug #617004.
Created attachment 161504 [details] [review] Use g_d[c]gettext() in gsettings Avoid using LC_MESSAGES, and just call g_dgettext directly. Bug #617004.
Review of attachment 161503 [details] [review]: Looks fine, but no g_dcpgettext() please.
Review of attachment 161504 [details] [review]: looks ok. please commit with trivial modification. ::: gio/gsettings.c @@ +990,2 @@ else + translated = g_dgettext (domain, unparsed); i guess you missed removing the now-unused lc_category variable.
(In reply to comment #9) > It may be appropriate to open another bug about the more general issue, but I'm > not sure that there is a particularly high level of interest in no-gettext > glib. Okay, so I won't put more work into that. It's just a workaround anyway. The real issue is that Glib's code generators (glib-mkenums, etc.) depend themselves on Glib, which is the root of all the trouble with Glib and cross compiling. Is there any chance to get _that_ fixed? Would it make sense to open a separate bug report on that?
> (glib-mkenums, etc.) depend themselves on Glib Not sure where you are going with this...glib-mkenums is a perl script.
(In reply to comment #15) > > (glib-mkenums, etc.) depend themselves on Glib > > Not sure where you are going with this...glib-mkenums is a perl script. I was talking about glib-genmarshal, not glib-mkenums. Sorry for the confusion. Also, the same problems holds with gobject-query, glib-compile-schemas and probably other helper programs. It would be great if none of these tools depended on the glib/gio/etc. stuff. That way, Glib would cross compile flawlessly in one step, without any need for a two-stage build.
Committed with the changes requested by desrt on irc.
As for its original context, this bug is definitely fixed. More general discussions should be done elsewhere. The list might even be more appropriate than bugzilla for such open-ended discussion.