Reini Urban wrote:
> Dave Page schrieb:
>> On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net>
>> wrote:
>>> Yes.
>>>
>>> As in the cygwin build does build. Nobody really has verified if the fix
>>> is needed there. But frankly, if you are likely to care about the
>>> effects of this issue, you won't be running cygwin anyway. It's mostly a
>>> dead platform for postgresql anyway, AFAICS we only keep it building for
>>> legacy compatibility. Once it starts taking lots of resources to keep
>>> building (which it doesn't now), I think we should just drop it
>>> instead...
>
> "Dead" is interesting. We see a lot of cygwin users having postgresql
> installed.
Heh. Maybe not dead, but certainly not really alive either ;-) Given the
evidence in your patch that clearly 8.3 isn't quite up to speed on
cygwin, and nobody has really noticed until now.
>> FWIW, the most recent packages from Cygwin themselves are 8.2.5.
>
> Update: 8.2.9 is latest.
Good!
> 8.3.x not because the new SSPI doesn't work yet.
>
> currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java
> --with-ossp-uuid --with-ldap
> (but ldap works okay with 8.2.9)
>
> currently testing is: --enable-nls --with-CXX --with-openssl --with-perl
> --with-python --with-libxml --with-libxslt
>
> current cygwin patch in testing is attached.
I assume this is a WIP and not actually for application, right? Please
look it over because it contains a number of pure-whitespace changes
that make it harder to read, and that will just end up being undone by
pgindent at a later date anyway.
I also notice this in auth.c:
+#ifdef·__CYGWIN__
+#define·WIN32
+#endif
What is the need to change this for just one file? Seems very fragile -
the rest of our codebase assumes WIN32 != CYGWIN, and I think we should
keep that consistent.
There's also a number of:
-#ifndef·WIN32
+#if·!defined(WIN32)·||·defined(__CYGWIN__)
If I read that right, it shouldn't be necessary as long as the WIN32
define is not set on CYGWIN?
And finally:
-············VALUE·"OriginalFilename",·"libpq.dll\0"
+············VALUE·"OriginalFilename",·"cygpq.dll\0"
This obviously has to be done another way, because that change will
affect the win32 platform as well...
//Magnus