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 all and 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
