Re: Problems using gettext on Windows

[Bruno Haible]

Hello,

Joerg Henrichs wrote:
> I got problem on Windows: 
> setting LANGUAGE inside of supertuxkart and then re-initialising (or 
> even initialising for the first time) gettext does not work, I am still 
> getting the original language (for the record, it works fine on Linux 
> and Mac, and I can change the language before starting supertuxkart on 
> Windows by setting LANGUAGE as expected).

Setting LANG and/or LANGUAGE from the parent process is indeed the
more important use-case that is tested more frequently.

> To set LANGUAGE I tried using:
>                  bool r1=SetEnvironmentVariableA("LANGUAGE", "de");
>                  bool r2=SetEnvironmentVariableW(L"LANGUAGE", L"de");
>                  bool r3=SetEnvironmentVariable ("LANGUAGE", "de");
>                  int r4=putenv("LANGUAGE=de");
>                  int r5=_putenv("LANGUAGE=de");

Hmm, these are those that I would have tried as well.

> Reading your FAQ this is apparently a known issue

Two of the FAQ questions apply:
  <http://www.gnu.org/software/gettext/FAQ.html#integrating_noop>
  <http://www.gnu.org/software/gettext/FAQ.html#windows_setenv>
I'm glad you reviewed them already.

So it appears like the problem you are seeing is with different copies of
the C library.

> PS: Not sure if this is related: I have also problems using fprintf with 
> gettext - it just crashes with
>    Access violation writing location 0x00000010.
> the first time a fprintf is done. I worked around this by adding a
> #undef fprintf
> after including libintl.h (which re-defines fprintf). Perhaps this might 
> be somehow related to the above issue?

Indeed, this too is an indication that you are using different C library
versions at the same time.

> All components I compile from scratch are compiled and linked with /MD 
> (multithreaded dll) - but supertuxkart depends on several other 
> libraries (irrlicht, alut, ogg, vorbis, libcurl, ...) which are outside 
> of my control.

If you can't sort out this problem with the various C libraries, I guess
your simplest way out is to build a Cygwin binary rather than a native
Windows binary. Cygwin is much closer to POSIX than mingw + gnulib, and
Cygwin has only one C library (assuming you don't mix Cygwin 1.5.x and
Cygwin 1.7.x).

Bruno
-- 
In memoriam Amar Singh Chamkila 
<http://en.wikipedia.org/wiki/Amar_Singh_Chamkila>