Re: Problems using gettext on Windows

[Joerg Henrichs]

Hi,

as a quick update for other people who might have the same problem:
I tried compiling gettext (and libiconv) from scratch using mingw+msys.
While compilation worked out of the box, it still had the same problems
as before (i.e. somehow using the wrong getenv, and therefore not
picking up any changes in LANGUAGE done while the application was running).

I then tried adding a new 'set_override_language' function (allowing you
to define a language setting which would override any specifications in
the environment variables). This worked fine while debugging, but then I
realised that my self-built library just crashed when using a release
build.

At this stage I had enough of trying to get this combination to work.
Instead we decided to use tinygettext for supertuxkart, which (after a
few minor changes) compiled fine with VS (and linux and OSx), and this
works fine.

Might be worth to update the FAQ to include some of the problems people
might have ;)

Again thanks a lot for your help!
   Joerg


Joerg Henrichs wrote:
> Hi Bruno,
> 
> 
> ...
>> Ouch. I cannot believe that the code of libintl_fprintf is so broken.
> For what's it worth, I can also recreate the problems of changing the
> language by setting LANGUAGE in a program not working with a simple
> hello world program. In case that anyone is interested, it's below
> (perhaps I did something wrong??)
> 
> I just can't believe that no one else had that problem before. I might
> check some other open source programs that support translations under
> windows, and see what they are doing.
> 
>> But I don't remember to which C library the binaries you got - from
>> January 2004, 7 years old - link against. Also I don't know to which
>> C library your programs link against, when - as you say - you compile
>> with /MD.
> My suspicion is that the binaries were last tested with version of
> VisualStudio before 2008, and that e.g. getenv etc. were completely
> changed by now.
> 
>> The right thing to so would be to rebuild libiconv and gettext from source
>> with your compiler; then you would have the guarantee that it combines
>> well with the other parts of your project. But that takes time; especially
>> if you don't have Cygwin installed.
> I have cygwin installed, but still getting gettext (and also iconv) to
> compile is not trivial. I've tried doing this a while ago, but then
> found the #undef fprintf work around and decided that's good enough for
> now :)
> 
> 
>> For my part, I've learned the lesson from these complexities: Newer versions
>> of my packages are tested with mingw only. There's only one binary format of
>> mingw .o and .dll files, no risk of mixing stuff that's meant to be linked
>> against different C library versions. I'm sorry if this disappoints you,
>> but I think it's a waste of time for GNU maintainers to struggle with a
>> platform where every new version of the C compilers brings 2 or 3 new
>> versions of the C library.
> I can understand your reasoning, but wouldn't it be possible to support
> VS by providing VS project files? For someone with understanding of the
> gettext sources and some windows background it shouldn't be that
> difficult (I assume here of course that there aren't any too specific
> unix only calls being used. I mean after all gettext is just reading a
> file, and doing some hashing and string manipulations :)  ). I admit
> that I tried that, but being myself a unix person it was just getting to
> difficult to work out the proper defines for windows :(
> 
> Is there by chance a undocumented function in gettext I can call to set
> the language to use instead of relying on the environment variable?
> 
> I'll try a few more things myself:
> - compiling iconv/gettext from scratch with mingw (either in cygwin or
>   msys), and if that works, add a 'setLanguage' function that takes
>   precedence over the environment variables (we distribute dependency
>   packages for our users, so we can easily (for windows) change the
>   API).
>   I had problems compiling iconv on mingw with cygwin before, but will
>   try a clean rebuild on a new cygwin installation first, since I might
>   have messed up something.
> - Try using the mingw created config.h files to make gettext compile in
>   VS.
> 
> But if any of this doesn't work as expected (i.e. it looks like I am
> wasting more time on those issues), I might just either try tinygettext,
> or even write a small gettext lib myself *sigh* By now I would be done
> with either I'd guess :(
> 
> 
>> On Linux, Solaris, and MacOS X you also have two binary formats (32-bit and
>> 64-bit), but there at least the linker produces an error when you try to
>> link stuff together that doesn't fit together.
> Agreed :) On the other hand, I think VS (VS 2008 , which is version 9.0)
> does print a warning if you have a conflict in the libs you are linking
> with. I am just not sure what happens if you link in a lib that requires
> itself a different lib. I would have expected to get a linker error in
> this case (unresolved externals), or a linker warning if you then force
> to link in the 'other' libc ... but that's MS for you (using the same
> names for incompatible externals???)
> 
> Thanks a lot for your help!
>    Joerg
> 
>> Bruno
> 
> #include <windows.h>
> #include <locale.h>
> #include <stdio.h>
> #include "libintl.h"
> #undef fprintf
> 
> #define _(a) gettext(a)
> 
> int main(int argc, char* argv[])
> {
>     setlocale(LC_ALL, "");
>     bindtextdomain("test", ".");
>     bind_textdomain_codeset("test", "ASCII");
>     textdomain ("test");
> 
>     fprintf(stderr, _("Hello world stderr\n"));
> 
>     // ==TRUE to avoid performance warning c4800
>     bool r1=SetEnvironmentVariableA("LANGUAGE", "de")==TRUE;
>     bool r2=SetEnvironmentVariableW(L"LANGUAGE", L"de")==TRUE;
>     bool r3=SetEnvironmentVariable ("LANGUAGE", "de")==TRUE;
>     int r4=putenv("LANGUAGE=de");
>     int r5=_putenv("LANGUAGE=de");
> 
>     setlocale(LC_ALL, "");
>     bindtextdomain("test", ".");
>     bind_textdomain_codeset("test", "ASCII");
>     textdomain ("test");
> 
>     fprintf(stderr, _("Hello world stderr\n"));
>         return 0;
> }
>