Re: win32.mak patch

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
> "_WINDOWS"
> /Fp".\Release\libpq.pch" /Fo".\Release\\" /Fd".\Release\\" /FD /c /D
> "_CRT_S
> ECURE_NO_DEPRECATE" /D "WIN64" /Wp64 /GS /D ENABLE_THREAD_SAFETY "win32.c"
> 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
wrong.

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?

//Magnus