Magnus Hagander wrote:
#ifdef WIN32
#include "win32.h"
#ifndef _WIN32_IE
#define _WIN32_IE 0x0400
I beleive his will break if _WIN32_IE is previously defined as something
<0x0400. Not sure if we build with a patform SDK with that old defaults
at all, but just to be sure it's probably better t
>>>The error appears to be on line that uses NEAR and complains
>about it
>>>... I see that the MinGW windef.h defines NEAR as empty, while
>>>the MSVC
>>>windef.h defines it as "near". Don't know if that makes a difference.
>>>
>>>
>>
>>Some reading up on MSDN gives this:
>>http://msdn.mic
>Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>Creating library .\Release\libpqdll.lib and object
>.\Release\libpqdll.exp
>> libpq.lib(fe-connect.obj) : error LNK2019: unresolved
>external symbol
>> [EMAIL PROTECTED] referenced in function
>_pqGetHomeDirectory
>> .\Release\libpq.dll : fatal
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp
> libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol
> [EMAIL PROTECTED] referenced in function _pqGetHomeDirectory
> .\Release\libpq.dll : fatal error LNK11
Magnus Hagander wrote:
The error appears to be on line that uses NEAR and complains about it
... I see that the MinGW windef.h defines NEAR as empty, while
the MSVC
windef.h defines it as "near". Don't know if that makes a difference.
Some reading up on MSDN gives this:
http://msdn.microso
>>>The trouble seems to come from these 2 lines:
>>>
>>>+ #define _WIN32_IE 0x0400
>>>+ #include
>>>
>>>First, on MSVC, _WIN32_IE is already defined at that point.
>If you get
>>>around that then processing the include file causes errors.
>>>
>>>
>>
>>Interesting - mingw was supposed to use
Magnus Hagander wrote:
Recent changes to interfaces/libpg/fe-connect.c have broken
MSVC builds,
which I am reliably informed are definitely still required - at least
some uses of libpq.dll made with gcc apparently cause the resulting
builds or applications to blow up.
Can you get some mor
>Recent changes to interfaces/libpg/fe-connect.c have broken
>MSVC builds,
>which I am reliably informed are definitely still required - at least
>some uses of libpq.dll made with gcc apparently cause the resulting
>builds or applications to blow up.
Can you get some more specifics on that? We
Andrew Dunstan wrote:
Recent changes to interfaces/libpg/fe-connect.c have broken MSVC
builds, which I am reliably informed are definitely still required -
at least some uses of libpq.dll made with gcc apparently cause the
resulting builds or applications to blow up.
The trouble seems to come
Recent changes to interfaces/libpg/fe-connect.c have broken MSVC builds,
which I am reliably informed are definitely still required - at least
some uses of libpq.dll made with gcc apparently cause the resulting
builds or applications to blow up.
The trouble seems to come from these 2 lines:
+ #
10 matches
Mail list logo
