Re: stat() vs cygwin - Mailing list pgsql-hackers

Magnus Hagander schrieb:
> 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.

Sure. This is just the current status of my patch (still from 8.3beta2), 
nothing to actually submit.

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

SSPI has some direct winapi calls to libsecure32 which are simpliest to 
declare by this cygwin == WIN32 declaration in the backend.
For the client libpq this is not so easy, I still have troubles 
seperating this.

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

This is only for the special case cygwin == WIN32. Just to be sure while 
testing I wrote it this way.

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

Sure :) This is only vendor private.
-- 
Reini