Re: mingw check hung
От | Andrew Dunstan |
---|---|
Тема | Re: mingw check hung |
Дата | |
Msg-id | 4981A9E4.9050806@dunslane.net обсуждение исходный текст |
Ответ на | Re: mingw check hung (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: mingw check hung
|
Список | pgsql-hackers |
Magnus Hagander wrote: >> Specifically, it's the SetEnvironmentVariable() call from >> pgwin32_putenv() called from pgwin32_unsetenv(). When this is disabled >> things work just fine. >> > > That's strange :( What arguments are it sent to the function? Since this > is an API function, it really shouldn't behave differently between mingw > and msvc, so it must be something that goes wrong with the arguments. > > Also, Tom mentioned earlier that we may be including *two* replacements > for unsetenv(), which could be what's causing the problem. Can you check > if that is happening and try to disable the one in port/unsetenv.c and > see if that changes things? > > > I've already ruled out that hypothesis by forcing the call direct to pgwin32_unsetenv() instead of relying on the macro, in initdb.c. There are only two such calls in initdb.c: the arguments are "LC_ALL" and "PGCLIENTENCODING". I wonder if this version of SetEnvironmentVariable is sufficiently dumb that it fails badly if given a NULL second argument for a value that is not in fact in the environment (as I would normally expect of these on Windows)? cheers andrew
В списке pgsql-hackers по дате отправления: