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.
I eventually gave up and just built a connection string instead - for
reference the final patch is here
http://postgis.refractions.net/pipermail/postgis-commits/2008-January/000199.html.
I appreciate it may not be 100% relevant, but I thought I'd flag it up
as possibly being a fault with the MingW putenv implementation.
HTH,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
