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

From Andrew Dunstan
Subject Re: pgsql: Add putenv support for msvcrt from Visual Studio 2013
Date
Msg-id 571E6D90.7050903@dunslane.net
Whole thread Raw
In response to Re: pgsql: Add putenv support for msvcrt from Visual Studio 2013  (Christian Ullrich <chris@chrullrich.net>)
Responses Re: pgsql: Add putenv support for msvcrt from Visual Studio 2013
List pgsql-committers

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:
>>
>>> * Magnus Hagander wrote:
>>>
>>> Add putenv support for msvcrt from Visual Studio 2013
>>> http://git.postgresql.org/pg/commitdiff/9f633b404cb3be6139f8dfdea00538489ffef9ab
>>>
>
>>> 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"?
>>
>> Fixing it should probably be as easy as trying each dll with the
>> specified
>> name and also with a "d" as a suffix?
>
> I think so, yes.
>
> Personally, I would have expected that at least the debug/release DLLs
> of a single CRT version would somehow share their environment, but I
> tried it and they don't.
>

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

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

cheers

andrew



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Try harder to detect a port conflict in PostgresNode.pm.
Next
From: Tom Lane
Date:
Subject: pgsql: New method for preventing compile-time calculation of degree con