Re: win32.mak patch
От | Magnus Hagander |
---|---|
Тема | Re: win32.mak patch |
Дата | |
Msg-id | 20080108140153.GH25881@svr2.hagander.net обсуждение исходный текст |
Ответ на | Re: win32.mak patch ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>) |
Ответы |
Re: win32.mak patch
("Dave Page" <dpage@postgresql.org>)
|
Список | pgsql-patches |
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
Вложения
В списке pgsql-patches по дате отправления:
Предыдущее
От: "Kevin Grittner"Дата:
Сообщение: Re: [HACKERS] OUTER JOIN performance regression remains in 8.3beta4
Следующее
От: Tom LaneДата:
Сообщение: Re: [HACKERS] OUTER JOIN performance regression remains in 8.3beta4