Thread: Re: [PATCHES] patch win32.mak of libpq
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