Skip site navigation (1) Skip section navigation (2)

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
Message-ID: (view raw, whole thread or download thread mbox)
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?


In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2008-01-08 21:11:16
Subject: Re: OUTER JOIN performance regression remains in 8.3beta4
Previous:From: Kevin GrittnerDate: 2008-01-07 16:07:24
Subject: Re: OUTER JOIN performance regression remains in8.3beta4

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group