Mark Cave-Ayland wrote:
> Magnus Hagander wrote:
>
>> Per discussion I looked at just reverting that part, but that won't
>> work. If we do that, the call to SetEnvironmentVariable() will not be
>> run, which certainly isn't right..
>>
>> The problem has to be in win32env.c. I originally thought we
>> accidentally called the putenv function twice in this case, but that
>> code seems properly #ifdef:ed to MSVC.
>>
>> I'm not sure I trust the crash point at all - is this compiled with
>> debug info enabled? It seems like a *very* strange line to crash on...
>>
>> I can't spot the error right off :-( Can you try to see if it's the
>> putenv() or the unsetenv() that gets broken? (by making sure just one of
>> them get replaced)
>>
>> //Magnus
>
> Hi guys,
>
> Don't know if this is relevant at all, but it reminds me of a problem I
> had with environment variables in PostGIS with MingW. It was something
> along the lines of environment variables set in a MingW program using
> putenv() for PGPORT, PGHOST etc. weren't visible to a MSVC-compiled
> libpq but were to a MingW-compiled libpq. It's fairly easy to knock up a
> quick test program in C to verify this.
That's the reason for this patch to go in in the first place. That has
been fixed. It also seems to have caused crashes on mingw, which was not
expected :-)
It's not actually a fault with mingw putenv, it's just that those go
into the cached environment only.
//Magnus
