win32.mak patch

Ummm, Sorry...former patch to be disregarded.
Although 64bit mak is experimental, it needs to be compiled.
Please apply this.

----- Original Message -----
From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>

Hi Magnus.

It is a thing left behind.:-(
Please apply it. thanks!

Regards,
Hiroshi Saito

--------------------------------------------------------------------------------

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?

//Magnus

Hi.

----- Original Message -----
From: "Magnus Hagander" <magnus@hagander.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?

Regards,
Hiroshi Saito

On Thu, Dec 20, 2007 at 10:02:24AM +0900, Hiroshi Saito wrote:

Hi.

----- Original Message -----
From: "Magnus Hagander" <magnus@hagander.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

Hi Magnus.

From: "Magnus Hagander" <magnus@hagander.net>

<snip>

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.

Umm,... It is very strange.?_?
C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) as below...
--
#ifdef _USE_32BIT_TIME_T
#ifdef _WIN64
#error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
#undef _USE_32BIT_TIME_T
#endif
#else
#if _INTEGRAL_MAX_BITS < 64
#define _USE_32BIT_TIME_T
#endif
#endif
--

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?

Ah yes, however, the 64-bit build environment is created by the command which Microsoft
offers.
As for it, CPU=AMD64 is already defined. Then, I look at a good result after your patch.
http://winpg.jp/~saito/pg83/WIN32MAK_AMD64_PATCH.txt

Regards,
Hiroshi Saito

On 08/01/2008, Magnus Hagander <magnus@hagander.net> wrote:

On Thu, Dec 20, 2007 at 10:02:24AM +0900, Hiroshi Saito wrote:

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?

That makes sense to me - why dictate to client apps when we don't need
to. We can always change the check in the future in the unlikely event
that we do expose time_t - which I can't imagine being in anything
other than a major release.

/D

On Wed, Jan 09, 2008 at 02:40:42PM +0900, Hiroshi Saito wrote:

Hi Magnus.

From: "Magnus Hagander" <magnus@hagander.net>

<snip>

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.

Umm,... It is very strange.?_?
C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) as
below...
--
#ifdef _USE_32BIT_TIME_T
#ifdef _WIN64
#error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
#undef _USE_32BIT_TIME_T
#endif
#else
#if _INTEGRAL_MAX_BITS < 64
#define _USE_32BIT_TIME_T
#endif
#endif
--

Yes, it's strange - I don't have that. Different versions, I guess.

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?

Ah yes, however, the 64-bit build environment is created by the command
which Microsoft offers.
As for it, CPU=AMD64 is already defined. Then, I look at a good result
after your patch.
http://winpg.jp/~saito/pg83/WIN32MAK_AMD64_PATCH.txt

Ok. My build env is probably broken then for 64-bit. I'll go ahead and
apply this patch then.

//Magnus