Re: SSPI vs MingW

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Dave Page <dpage(at)postgresql(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSPI vs MingW
Date: 2007-07-23 12:55:27
Message-ID: 20070723125527.GG29554@svr2.hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 23, 2007 at 11:06:59AM +0100, 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.

Indeed.

> > 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...

Heh, well, I don't see that one going away...

> > 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.

Ok, jus so people knowing what amount of code we're talking about, here's a
patch that does this. Awaiting further comments :-)

//Magnus

Attachment Content-Type Size
sspi.diff text/plain 2.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2007-07-23 13:09:19 Re: SSPI vs MingW
Previous Message Dave Page 2007-07-23 10:06:59 Re: SSPI vs MingW