Re: win32.mak patch

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: win32.mak patch
Date: 2008-01-08 14:01:53
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

On Thu, Dec 20, 2007 at 10:02:24AM +0900, Hiroshi Saito wrote:
> Hi.
> ----- Original Message -----
> From: "Magnus Hagander" <magnus(at)hagander(dot)net>
> >On Wed, Dec 19, 2007 at 11:19:54AM +0900, Hiroshi Saito wrote:
> >>Ummm, Sorry...former patch to be disregarded.
> >>Although 64bit mak is experimental, it needs to be compiled.
> >>Please apply this.
> >
> >Is this really correct? Fromw hat I can tell you *both* tell us not to
> >check the value *and* set the value? Shouldn't we be doing just one of
> >them?
> The setup is not allowed in 64-bit build of VisualStudio. Then, It is not
> allowed although I use nmake. I did the work of 64-bit correspondence
> of 8.3 to libpq. However, Although it is not declared by release, win32.mak
> has. I said that 64 bits of libpq(s) were required, in order that psqlODBC
> might guide 64 bits formally. Then, I and Inoue-san have lost timing in the
> reason for not having sufficient examination environment. But, We have
> compile environment. Then, It borrows an external machine and has performed
> only the easy examination....
> -- add the _USE_32BIT_TIME_T for 64bit compile environment --
> echo #define SYSCONFDIR "" > pg_config_paths.h
> cl.exe /nologo /W3 /EHsc /O2 /MD /I "..\..\include" /I
> "..\..\include\po
> rt\win32" /I "..\..\include\port\win32_msvc" /I "..\..\port" /I. /I
> "C:\OpenSSL\
> include" /D "FRONTEND" /D NDEBUG /D _USE_32BIT_TIME_T /D "WIN32" /D
> /Fp".\Release\libpq.pch" /Fo".\Release\\" /Fd".\Release\\" /FD /c /D
> "_CRT_S
> win32.c
> C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) :
> fatal err
> or C1189: #error : You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with
> _WIN64
> NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Platform
> SDK\Bin\nmake.e
> xe"' : return code '0x2'
> Stop.
> -- END --
> I'm always realistic. what do you think?

I see the problem now. In my dev kit, there is no error for using
_USE_32BIT_TIME_T on Win64. That's why I got caught up in your patch being

A question there though - do we care about the length of time_t on client
platforms, or should we instead just disable the whole check for the
client? AFAICS we don't expose time_t at all on the client, so why should
we force libpq *clients* to build with 32-bit time_t? Shouldn't we go with
the attached patch instead?

It makes the win64 compile pass for me, but the linker step fails badly with:
libpqdll.def : error LNK2001: unresolved external symbol PQbackendPID
libpqdll.def : error LNK2001: unresolved external symbol PQbinaryTuples
libpqdll.def : error LNK2001: unresolved external symbol PQcancel
libpqdll.def : error LNK2001: unresolved external symbol PQclear

for every export we have. Hiroshi, do you see that as well, or is something broken
in my win64 environment? I'm running "nmake /f win32.mak CPU=AMD64" to
build per our documentation, is that correct?


Attachment Content-Type Size
libpq.diff text/plain 987 bytes

In response to


Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-01-08 21:11:16 Re: OUTER JOIN performance regression remains in 8.3beta4
Previous Message Kevin Grittner 2008-01-07 16:07:24 Re: OUTER JOIN performance regression remains in 8.3beta4