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:

Previous
From: Magnus Hagander
Date:
Subject: Re: [PATCHES] patch win32.mak of libpq
Next
From: "Hiroshi Saito"
Date:
Subject: Re: [PATCHES] patch win32.mak of libpq