On Wed, Sep 2, 2020 at 5:21 PM Dave Page <dp...@pgadmin.org> wrote: > > > On Wed, Sep 2, 2020 at 2:47 PM Stephen Frost <sfr...@snowman.net> wrote: > >> Greetings, >> >> * Dave Page (dp...@pgadmin.org) wrote: >> > On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost <sfr...@snowman.net> >> wrote: >> > > * Dave Page (dp...@pgadmin.org) wrote: >> > > > Attached is a patch against 12.4 for the build system in case anyone >> > > wants >> > > > to play (I'll do it properly against the head branch later). I'm >> guessing >> > > > this will work for < 12, as with 12 I'm now getting the following >> which >> > > > looks like it's related to GSS encryption: >> > > > >> > > > "C:\Users\dpage\Downloads\postgresql-12.4\pgsql.sln" (default >> target) >> > > (1) -> >> > > > "C:\Users\dpage\Downloads\postgresql-12.4\pgcrypto.vcxproj" (default >> > > > target) (2) -> >> > > > "C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj" (default >> > > > target) (3) -> >> > > > (Link target) -> >> > > > be-secure-gssapi.obj : error LNK2019: unresolved external symbol >> setenv >> > > > referenced in function secure_open_gssapi >> > > > [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj] >> > > > .\Release\postgres\postgres.exe : fatal error LNK1120: 1 >> unresolved >> > > > externals >> [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj] >> > > > >> > > > I'll dig into that some more. >> > > >> > > Yes, that'd be in the GSSENC code, which I hadn't been expecting to be >> > > used under Windows. If you're successful, I don't have any issue >> > > helping to make that work, though I'm curious if you're trying to >> build >> > > with MIT KfW (which is rather ancient these days, being based on krb5 >> > > 1.13 and not updated since..) or with a more current release...? >> > >> > I'm currently using the KFW 4.1 build from MIT. I've tried building it >> > myself but it requires a very old toolchain (which defeated the point of >> > what I was trying to do at the time). >> >> > I haven't yet looked to see if the source for krb5-1.8.2 will build or >> even >> > has the right bits in it for Windows - as I'm sure you know MIT seem to >> > maintain an entirely different version for Windows for which I assume >> > there's a reason. >> >> I'm a bit confused as to why you'd consider trying 1.8.2- did you mean >> 1.18.2 there, perhaps..? > > > Yes, typo. > > >> That's what I would think to try, since, as I >> understand it from following the Kerberos Dev list (which is pretty >> responsive...) has been updated to work with newer Windows build >> toolchains. >> > > OK, will try to do that tomorrow. > > Thanks! >
OK, so 1.18.2 builds OK. It's a bit of a faff, but nothing major. It seems to work fine as a standalone set of tools. Of course, they've changed the installation paths again - they've dropped the i386 and amd64 parts from the library path :-/ So having rebuilt PostgreSQL against that, I'm now in the situation where the server never even attempts to get a ticket as far as I can see, and psql just crashes with nothing more than a useless error in the event log: Faulting application name: psql.exe, version: 14.0.0.20246, time stamp: 0x5f50e477 Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x0000000000000000 Faulting process id: 0xd10 Faulting application start time: 0x01d681f189a17360 Faulting application path: C:\pg\bin\psql.exe Faulting module path: unknown Report Id: eb68d787-1c82-420d-8878-bc0648932a5d Faulting package full name: Faulting package-relative application ID: So I'm going to have to break out the debugger, though I suspect this may require more effort than I have time for right now. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com
