Re: pgsql: Add putenv support for msvcrt from Visual Studio 2013 - Mailing list pgsql-hackers

From Christian Ullrich
Subject Re: pgsql: Add putenv support for msvcrt from Visual Studio 2013
Date
Msg-id 9d5c6a49-774c-44de-83fc-65c5b431f8d9@chrullrich.net
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pgsql: Add putenv support for msvcrt from Visual Studio 2013  (Christian Ullrich <chris@chrullrich.net>)
List pgsql-hackers
* Andrew Dunstan wrote:

> On 04/25/2016 09:27 AM, Christian Ullrich wrote:
>> * Magnus Hagander wrote:
>>
>>> On Sun, Apr 24, 2016 at 9:56 PM, Christian Ullrich
>>> <chris@chrullrich.net> wrote:

>>>> Just noticed something. This DLL detection by name has never worked in
>>>> debug builds where the DLL names end in "d". Is that important?
>>
>>> That's an interesting point.  I guess our release builds are never with
>>> debugging info - but could it make the buildfarm "wrong"?

> What if both are present? Is a release build prevented from loading a
> debug dll and vice versa?

Debug and release are simply two separate CRTs. If your process contains
a module that needs the one, and another that needs the other, you will
have both loaded at once.

I had hoped they might share state, but they don't, at least as far as
putenv()/getenv() are concerned.

> Alternatively, can we detect at compile time if we are a debug build and
> if so add the suffix?

No; same reason as above.

--
Christian



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013
Next
From: Shay Rojansky
Date:
Subject: Re: Proposed change to make cancellations safe