Dave Page wrote:
> Magnus Hagander wrote:
>
>> I just came across yet another place where MingW isn't compatible with the
>> windows api. Specifically, their libsecur32.a file lacks at least one
>> function that is needed to implement SSPI authentication. The way I can see
>> it, there are three ways to solve it:
>>
>
> Ugh.
>
agreed.
>
>> 1) Simply state that SSPI authentication in the backend cannot be built
>> with mingw, and require msvc build for it (the msvc api follows the windows
>> api, which is hardly surprising). We could add an autoconf test for it
>> that'd pick up an updated libsecur32.a file if/when mingw release an
>> update.
>>
>
> I prefer this option, if only because I have little interest in
> supporting mingw any longer than necessarily, but I realise others may
> want to use it so...
>
I don't think it's going away any time soon. For example, it's the only
platform I've been able to make work on my Vista box, and nobody has
told me how to get around the problems, even though apparently some have
managed to make MSVC work on Vista.
This is the least good option IMNSHO.
>
>> 2) Ship our own secur32.def file, and automatically build an import library
>> for it that we can link against. Because the function is present in the DLL
>> file, this works fine.
>>
>
> Yuck.
>
>
>> 3) Dynamically load the function at runtime, thus completely ignoring the
>> need for an import library for it.
>>
>
> That gets my vote. It's relatively clean and non-kludgy.
>
>
>
Yes, I can live with this one too, although I don't think option 2 is so
bad either.
cheers
andrew