Thread: patch win32.mak of libpq
Hi Magnus, and Dave.
Sorry, I'm a somewhat late reaction... This is the present correspondence.
However, VC6 does not support SSAPI. Therefore, the next release makes
VC6 the outside of an object.
-- VC6
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
Building the Win32 static library...
Using default OpenSSL Include directory: C:\OpenSSL\include
Using default OpenSSL Library directory: C:\OpenSSL\lib\VC
Using default Kerberos Include directory: C:\kfw-2.6.5\inc
Using default Kerberos Library directory: C:\kfw-2.6.5\lib\i386
echo #define SYSCONFDIR "" > pg_config_paths.h
link.exe @C:\DOCUME~1\hiroshi\LOCALS~1\Temp\nma00120.
LINK : fatal error LNK1181: (snip japanese) "secur32.lib" (snip japanese)
NMAKE : fatal error U1077: 'link.exe' : (snip japanese) '0x49d'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\N
MAKE.EXE"' : (snip japanese) '0x2'
Stop.
-- VC8
Microsoft(R) Program Maintenance Utility Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Building the Win32 static library...
Using default OpenSSL Include directory: C:\OpenSSL\include
Using default OpenSSL Library directory: C:\OpenSSL\lib\VC
Using default Kerberos Include directory: C:\kfw-2.6.5\inc
Using default Kerberos Library directory: C:\kfw-2.6.5\lib\i386
link.exe @C:\DOCUME~1\hiroshi\LOCALS~1\Temp\nm969.tmp
(snip japanese) .\Release\libpqdll.lib (snip japanese) .\Release\libpqdll.exp (snip
japanese)
cd ..\..
echo All Win32 parts have been built!
All Win32 parts have been built!
--
If there is no objection. Let's close support of VC6.
What do you think?
Regards,
Hiroshi Saito
Attachment
On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: > Hi Magnus, and Dave. > > Sorry, I'm a somewhat late reaction... This is the present correspondence. > However, VC6 does not support SSAPI. Therefore, the next release makes > VC6 the outside of an object. I think VC6 should support it Ok. You probably just need to upgrade your Platform SDK to a version that's for Windows 2000 or newer. I think VC6 shipws with the NT4 SDK by default. It looks like it' just missing secur32.lib. I have applied your patch, since it's used in either case. Thanks! > If there is no objection. Let's close support of VC6. > What do you think? While I don't disagree in principle, if you can test it with a new Platfrom SDK and see if that works there's no reason to close it (yet). //Magnus
Hi Magnus. Thanks! From: "Magnus Hagander" > On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: >> Hi Magnus, and Dave. >> >> Sorry, I'm a somewhat late reaction... This is the present correspondence. >> However, VC6 does not support SSAPI. Therefore, the next release makes >> VC6 the outside of an object. > > I think VC6 should support it Ok. You probably just need to upgrade your > Platform SDK to a version that's for Windows 2000 or newer. I think VC6 > shipws with the NT4 SDK by default. It looks like it' just missing > secur32.lib. Ahh yes. However, MS says.! The last SDK that will work with VC 6.0 is the February 2003 Edition. http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ this SDK is newer and does not support VC6.:-( > > I have applied your patch, since it's used in either case. Thanks! > >> If there is no objection. Let's close support of VC6. >> What do you think? > > While I don't disagree in principle, if you can test it with a new Platfrom > SDK and see if that works there's no reason to close it (yet). It seems that it is difficult to get public although I have it. Then, I feel that support is difficult.... I missed something? Regards, Hiroshi Saito Regards, Hiroshi Saito
On Wed, Jul 25, 2007 at 10:30:29PM +0900, Hiroshi Saito wrote: > >On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: > >>Hi Magnus, and Dave. > >> > >>Sorry, I'm a somewhat late reaction... This is the present correspondence. > >>However, VC6 does not support SSAPI. Therefore, the next release makes > >>VC6 the outside of an object. > > > >I think VC6 should support it Ok. You probably just need to upgrade your > >Platform SDK to a version that's for Windows 2000 or newer. I think VC6 > >shipws with the NT4 SDK by default. It looks like it' just missing > >secur32.lib. > > Ahh yes. However, MS says.! > The last SDK that will work with VC 6.0 is the February 2003 Edition. > http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ > this SDK is newer and does not support VC6.:-( Ooh. Wasn't aware of that :-( Now I see what you mean. Ok. So there are actually two ways to go about it: 1) Discontinue support for MSVC6 and require MSVC8 2) Change it so that MSVC6 can still build libpq, just not with SSPI support. This can be done by conditionally enabling ENABLE_SSPI, so it's not that hard. The question is, if we go with option 2, is it something that anybody actually will *use*? If I'm not mistaken, one of the original reasons we kept the win32.mak method around after we had the "complete msvc build" was for the ODBC folks. Are you saying that the ODBC guys are now happy with a MSVC8 build? //Magnus
Hi. From: "Magnus Hagander" > On Wed, Jul 25, 2007 at 10:30:29PM +0900, Hiroshi Saito wrote: >> >On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: >> >>Hi Magnus, and Dave. >> >> >> >>Sorry, I'm a somewhat late reaction... This is the present correspondence. >> >>However, VC6 does not support SSAPI. Therefore, the next release makes >> >>VC6 the outside of an object. >> > >> >I think VC6 should support it Ok. You probably just need to upgrade your >> >Platform SDK to a version that's for Windows 2000 or newer. I think VC6 >> >shipws with the NT4 SDK by default. It looks like it' just missing >> >secur32.lib. >> >> Ahh yes. However, MS says.! >> The last SDK that will work with VC 6.0 is the February 2003 Edition. >> http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ >> this SDK is newer and does not support VC6.:-( > > Ooh. Wasn't aware of that :-( Now I see what you mean. Yea, It is that there was nothing in public policy.... > > Ok. So there are actually two ways to go about it: > 1) Discontinue support for MSVC6 and require MSVC8 > > 2) Change it so that MSVC6 can still build libpq, just not with SSPI > support. This can be done by conditionally enabling ENABLE_SSPI, so it's > not that hard. > > The question is, if we go with option 2, is it something that anybody > actually will *use*? I desire 1 as formal. However, It contains VC7.1 and VC8. Moreover, libpq.dll can be used by the module of VC6. > > If I'm not mistaken, one of the original reasons we kept the win32.mak > method around after we had the "complete msvc build" was for the ODBC > folks. Are you saying that the ODBC guys are now happy with a MSVC8 build? Yes, They are offered as comfortable environment. pgAdmin and that's right.!:-) However, psqlODBC also contains legacy VC6. They will clear a problem by the cause libpq.dll wire. Even if it may be adjusted from now on. probably. Thanks!! Regards, Hiroshi Saito
Hiroshi Saito wrote: >> Ok. So there are actually two ways to go about it: >> 1) Discontinue support for MSVC6 and require MSVC8 >> >> 2) Change it so that MSVC6 can still build libpq, just not with SSPI >> support. This can be done by conditionally enabling ENABLE_SSPI, so it's >> not that hard. >> >> The question is, if we go with option 2, is it something that anybody >> actually will *use*? > > I desire 1 as formal. However, It contains VC7.1 and VC8. > Moreover, libpq.dll can be used by the module of VC6. Is there any actual reason to keep VC7.1 support? VC6 has one reason only to exist, and that's that it doesn't carry the dependencies that VC8 does. But VC7 does (different ones, but just as many). So if we're dropping support for VC6, my suggestion is that we drop support for *any* win32 compiler other than VC8 and MingW gcc. >> If I'm not mistaken, one of the original reasons we kept the win32.mak >> method around after we had the "complete msvc build" was for the ODBC >> folks. Are you saying that the ODBC guys are now happy with a MSVC8 >> build? > > Yes, They are offered as comfortable environment. pgAdmin and that's > right.!:-) > However, psqlODBC also contains legacy VC6. They will clear a problem by > the cause libpq.dll wire. Even if it may be adjusted from now on. probably. I'm sorry, I don't fully understand you here. Which one of the following three is it (or is it something else altogether)? 1) Does ODBC *require* a MSVC6 build libpq.dll? 2) Can ODBC work with MVC8 built libpq, but ODBC is built with MSVC6? 3) Can ODBC be built with MSVC8 and use the MSVC8 built libpq? It would be unfortunate if ODBC has to ship with a different set of dependencies than libpq, but as long as they build with either VC6 or VC8 that shouldn't happen. 1 above would be really bad, but I'm 99% sure that's not so, since I've actually tested SSPI auth with such a libpq. IMO, the best option would be 3, but I don't know enough about the ODBC driver to comment on there. I'll CC this to the odbc list so we can get more input from other people there. //Magnus
Hi Magnus and all. From: "Magnus Hagander" > Hiroshi Saito wrote: >>> Ok. So there are actually two ways to go about it: >>> 1) Discontinue support for MSVC6 and require MSVC8 >>> >>> 2) Change it so that MSVC6 can still build libpq, just not with SSPI >>> support. This can be done by conditionally enabling ENABLE_SSPI, so it's >>> not that hard. >>> >>> The question is, if we go with option 2, is it something that anybody >>> actually will *use*? >> >> I desire 1 as formal. However, It contains VC7.1 and VC8. >> Moreover, libpq.dll can be used by the module of VC6. > > Is there any actual reason to keep VC7.1 support? It is still used and has sufficient function. Then, Inoue-san is developing in the environment.:-) The project file of VC7.1 differs from VC8 a little. However, nmake.exe absorbs it. for the reasons, we are maintaining win32.mak. but, project file offers the minimum function in simple. MSDTC is a reason for being somewhat more complicated than standard compile. > > VC6 has one reason only to exist, and that's that it doesn't carry the > dependencies that VC8 does. But VC7 does (different ones, but just as many). > > So if we're dropping support for VC6, my suggestion is that we drop > support for *any* win32 compiler other than VC8 and MingW gcc. By the PostgreSQL main part, I think that you may limit with support of VC7.1, VC8, and MinGW (gcc) by SSPI to which you are working. Although our psqlODBC uses libpq.dll, a wired protocol realizes it. Although I have not tested SSPI yet, However, I am checking normal of compile. > > >>> If I'm not mistaken, one of the original reasons we kept the win32.mak >>> method around after we had the "complete msvc build" was for the ODBC >>> folks. Are you saying that the ODBC guys are now happy with a MSVC8 >>> build? >> >> Yes, They are offered as comfortable environment. pgAdmin and that's >> right.!:-) >> However, psqlODBC also contains legacy VC6. They will clear a problem by >> the cause libpq.dll wire. Even if it may be adjusted from now on. probably. > > I'm sorry, I don't fully understand you here. Which one of the following > three is it (or is it something else altogether)? > > 1) Does ODBC *require* a MSVC6 build libpq.dll? > 2) Can ODBC work with MVC8 built libpq, but ODBC is built with MSVC6? > 3) Can ODBC be built with MSVC8 and use the MSVC8 built libpq? > > It would be unfortunate if ODBC has to ship with a different set of > dependencies than libpq, but as long as they build with either VC6 or > VC8 that shouldn't happen. > > 1 above would be really bad, but I'm 99% sure that's not so, since I've > actually tested SSPI auth with such a libpq. > > IMO, the best option would be 3, but I don't know enough about the ODBC > driver to comment on there. I'll CC this to the odbc list so we can get > more input from other people there. I'm sure that 3 is sufficient. I will begin the preparation. Of course, if there is a problem, though it will be corrected. P.S) The present situation.(as for psqlODBC) Compile (VC6, VC8) does not look at a problem by CVS-HEAD of pgsql.!! But, The test is not completed....I apologize for the overdue work... Regards, Hiroshi Saito
Hi. Some test situations. As for PostgreSQL CVS HEAD(8.3beta). libpq is created by MinGW (gcc). As for psqlODBC CVS HEAD(08.02.0402) (linked SECUR32.dll) 1. VC6(psqlodbc.dsp) The run test of compile and a part is through in VC6. 2. VC8(psqlodbc.vcproj) The run test of compile and a part is through in VC8. This is one progress report. It will still continue. However, the check was completed.! Regards, Hiroshi Saito
Oops, An expressional mistake. > As for PostgreSQL CVS HEAD(8.3beta). > libpq is created by MinGW (gcc). > As for psqlODBC CVS HEAD(08.02.0402) > (linked SECUR32.dll) SECUR32.dll link is libpq.dll. SECUR32.dll does not link to psqlodbc35w.dll Regards, Hiroshi Saito
Hiroshi Saito wrote: >>>> Ok. So there are actually two ways to go about it: >>>> 1) Discontinue support for MSVC6 and require MSVC8 >>>> >>>> 2) Change it so that MSVC6 can still build libpq, just not with SSPI >>>> support. This can be done by conditionally enabling ENABLE_SSPI, so >>>> it's >>>> not that hard. >>>> >>>> The question is, if we go with option 2, is it something that anybody >>>> actually will *use*? >>> >>> I desire 1 as formal. However, It contains VC7.1 and VC8. >>> Moreover, libpq.dll can be used by the module of VC6. >> >> Is there any actual reason to keep VC7.1 support? > > It is still used and has sufficient function. Then, Inoue-san is > developing in the environment.:-) > The project file of VC7.1 differs from VC8 a little. However, nmake.exe > absorbs it. > for the reasons, we are maintaining win32.mak. but, project file offers > the minimum function > in simple. MSDTC is a reason for being somewhat more complicated than > standard compile. Ok. Just to be clear, do you need MSVC7.1 support, or do you need win32.mak/nmake support? I realize they both work here, but if we changed something else that needed MSVC8 but maintained the win32.mak file, would that be enough? Inoue-san, I'd be interested in knowing exactly what it is that is the problem with MSVC8, if it's easy enough to outline? >> 1) Does ODBC *require* a MSVC6 build libpq.dll? >> 2) Can ODBC work with MVC8 built libpq, but ODBC is built with MSVC6? >> 3) Can ODBC be built with MSVC8 and use the MSVC8 built libpq? >> >> It would be unfortunate if ODBC has to ship with a different set of >> dependencies than libpq, but as long as they build with either VC6 or >> VC8 that shouldn't happen. >> >> 1 above would be really bad, but I'm 99% sure that's not so, since I've >> actually tested SSPI auth with such a libpq. >> >> IMO, the best option would be 3, but I don't know enough about the ODBC >> driver to comment on there. I'll CC this to the odbc list so we can get >> more input from other people there. > > I'm sure that 3 is sufficient. I will begin the preparation. > Of course, if there is a problem, though it will be corrected. Great. Let me know if you need any assistance. //Magnus
On Fri, Jul 27, 2007 at 10:01:06PM +0200, Magnus Hagander wrote: > Hiroshi Saito wrote: > >>>> Ok. So there are actually two ways to go about it: > >>>> 1) Discontinue support for MSVC6 and require MSVC8 > >>>> > >>>> 2) Change it so that MSVC6 can still build libpq, just not with SSPI > >>>> support. This can be done by conditionally enabling ENABLE_SSPI, so > >>>> it's > >>>> not that hard. > >>>> > >>>> The question is, if we go with option 2, is it something that anybody > >>>> actually will *use*? > >>> > >>> I desire 1 as formal. However, It contains VC7.1 and VC8. > >>> Moreover, libpq.dll can be used by the module of VC6. > >> > >> Is there any actual reason to keep VC7.1 support? > > > > It is still used and has sufficient function. Then, Inoue-san is > > developing in the environment.:-) > > The project file of VC7.1 differs from VC8 a little. However, nmake.exe > > absorbs it. > > for the reasons, we are maintaining win32.mak. but, project file offers > > the minimum function > > in simple. MSDTC is a reason for being somewhat more complicated than > > standard compile. > > Ok. Just to be clear, do you need MSVC7.1 support, or do you need > win32.mak/nmake support? I realize they both work here, but if we > changed something else that needed MSVC8 but maintained the win32.mak > file, would that be enough? Since I've had no further feedback, I've applied a patch that changes the list of supported MSVC versions to 7.1-8.0, but keeping the win32.mak files. //Magnus
Hi Magnus. I'm sorry lateness of a reaction.. Thanks! P.S) Inoue-san is busy and worsens condition. Regards, Hiroshi Saito >> Ok. Just to be clear, do you need MSVC7.1 support, or do you need >> win32.mak/nmake support? I realize they both work here, but if we >> changed something else that needed MSVC8 but maintained the win32.mak >> file, would that be enough? > > Since I've had no further feedback, I've applied a patch that changes the > list of supported MSVC versions to 7.1-8.0, but keeping the win32.mak > files. > > //Magnus