Re: [PATCHES] patch win32.mak of libpq - Mailing list pgsql-odbc
From | Hiroshi Saito |
---|---|
Subject | Re: [PATCHES] patch win32.mak of libpq |
Date | |
Msg-id | 00f601c7cff3$46d5fca0$c601a8c0@HP22720319231 Whole thread Raw |
In response to | Re: [PATCHES] patch win32.mak of libpq (Magnus Hagander <magnus@hagander.net>) |
Responses |
Re: [PATCHES] patch win32.mak of libpq
|
List | pgsql-odbc |
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
pgsql-odbc by date: