bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems using gettext on Windows


From: Joerg Henrichs
Subject: Re: Problems using gettext on Windows
Date: Thu, 10 Mar 2011 11:16:44 +1100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

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;
}



reply via email to

[Prev in Thread] Current Thread [Next in Thread]