Magnus Hagander wrote:
> Hiroshi Inoue wrote:
>> Hiroshi Inoue wrote:
>>>>> Where are we on this?
>>> AFAICS there are 2 causes.
>>>
>>> 1. MSVC version of postgres is using a bad gettext module.
>>> 2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
>>>
>>> As for 1, we have to use another gettext module. I can provide it
>>> if requested.
>
> Yes, I think that'll be needed. Exactly what is wrong and needs to be
> changed? (Copying DAve in on this since he builds the MSI)
As far as I see, the libintl3.dll(version 0.14.4.1952) at
http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=17255&release_id=325693
was built under a bad configuration. In fact I can see HAVE_LC_MESSAGES
#defined in src\gettext\0.14.4\gettext-0.14.4\gettext-runtime\config.h.
Probably due to this mistake, the gettext module libint3.dll doesn't see the environment variables LC_MESSAGES etc at
alland tries to call setlocale() instead.
> Is it possible to build this one with the same version of MSVC? If it
> is, then that should remove the need for #2, right?
>
>>> As for 2, pg_putenv() or pg_unsetenv() in the attachced patch calls
>>> corresponding putenv() whose result can be referenced by getenv() in
>>> mingw.
>
> Oh, yuck. This must be because msvcrt.dll (used by mingw) caches the
> values in the environment.
>
> That's a rather ugly solution, but I guess if we have no other choice..
> Does it make a difference if you try to set the value using
> SetEnvironmentVariable()?
SetEnvironmentVariable() is called from the first in
pg_perm_setlocale().
> It would definitely work if the gettext stuff uses
> GetEnvironmentVariable().
Yes I think so.
> I doubt it does though, but it might work
> anyway...
>
>
>>> In addtion the patch provides a functionality to Windows locale
>>> name to ISO formatted locale name.
>>>
>>> Comments ?
>
> I wonder if it's cleaner to use this "load msvcrt version of setenv()"
> *always*. Or to cover all bases, perhaps we should always do *both* -
> that is, both set in current runtime and msvcrt.dll... We don't do this
> in a lot of places today, but we might use more in the future. And as
> long as it's not in a performance critical path, doing it twice is
> almost for free...
Agreed.
regards,
Hiroshi Inoue
