On Thu, Dec 20, 2007 at 10:02:24AM +0900, Hiroshi Saito wrote: > Hi. > > ----- Original Message ----- > From: "Magnus Hagander" <[EMAIL PROTECTED]> > > > >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
Index: src/include/port/win32.h =================================================================== RCS file: /projects/cvsroot/pgsql/src/include/port/win32.h,v retrieving revision 1.82 diff -c -r1.82 win32.h *** src/include/port/win32.h 11 Dec 2007 14:34:43 -0000 1.82 --- src/include/port/win32.h 8 Jan 2008 13:58:54 -0000 *************** *** 50,56 **** * On Mingw/Msys, that should always be the case, but MSVC++ defaults * to 64 bits. We set that for our own build in the project files */ ! #ifdef WIN32_ONLY_COMPILER #ifndef _USE_32BIT_TIME_T #error "Postgres uses 32 bit time_t - add #define _USE_32BIT_TIME_T on Windows" #endif --- 50,56 ---- * On Mingw/Msys, that should always be the case, but MSVC++ defaults * to 64 bits. We set that for our own build in the project files */ ! #if defined(WIN32_ONLY_COMPILER) && !defined(FRONTEND) #ifndef _USE_32BIT_TIME_T #error "Postgres uses 32 bit time_t - add #define _USE_32BIT_TIME_T on Windows" #endif
---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq