Re: [PATCHES] win32.mak patch
On Wed, Jan 09, 2008 at 02:40:42PM +0900, Hiroshi Saito wrote: > Hi Magnus. > > From: "Magnus Hagander" <[EMAIL PROTECTED]> > > > >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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] win32.mak patch
On 08/01/2008, Magnus Hagander <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] win32.mak patch
Hi Magnus. From: "Magnus Hagander" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] win32.mak patch
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.h11 Dec 2007 14:34:43 - 1.82 --- src/include/port/win32.h8 Jan 2008 13:58:54 - *** *** 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
Re: [PATCHES] win32.mak patch
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? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32.mak patch
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] 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" <[EMAIL PROTECTED]> Hi Magnus. It is a thing left behind.:-( Please apply it. thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster win32mak_patch2 Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] win32.mak patch
Hi Magnus. It is a thing left behind.:-( Please apply it. thanks! Regards, Hiroshi Saito win32mak_patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] win32.mak patch of pg_dump.
Patch applied and backpatched for 8.2.X. Sorry it didn't make it into 8.2.0. --- Hiroshi Saito wrote: > Hi. > > The module link is insufficient.:-( > > Sorry, japanese message change to xxx --- > link.exe @C:\DOCUME~1\hi-saito\LOCALS~1\Temp\nmk03360. > common.obj : error LNK2001: xx "_pg_qsort" xx > pg_dump_sort.obj : error LNK2001: x "_pg_qsort" x > .\Release\pg_dump.exe : fatal error LNK1120: xxx > NMAKE : fatal error U1077: 'link.exe' : x '0x460' > Stop. > > > Please apply it. > Thanks. > > Regards, > Hiroshi Saito [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] win32.mak patch of pg_dump.
Hi. The module link is insufficient.:-( Sorry, japanese message change to xxx --- link.exe @C:\DOCUME~1\hi-saito\LOCALS~1\Temp\nmk03360. common.obj : error LNK2001: xx "_pg_qsort" xx pg_dump_sort.obj : error LNK2001: x "_pg_qsort" x .\Release\pg_dump.exe : fatal error LNK1120: xxx NMAKE : fatal error U1077: 'link.exe' : x '0x460' Stop. Please apply it. Thanks. Regards, Hiroshi Saito pg_dump_win32_patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
