Bruce Momjian schrieb:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I'm confused. There is a Cygwin member of buildfarm, working quite
happily. Can you point me to the exact patch in question, please? I
tho
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >
> >> Alvaro Herrera wrote:
> >>
> >>> Andrew Dunstan wrote:
> >>>
> >>>
> I'm confused. There is a Cygwin member of buildfarm, working quite
> happily. Can you point me to the exact patch
Bruce Momjian wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I'm confused. There is a Cygwin member of buildfarm, working quite
happily. Can you point me to the exact patch in question, please? I
thought we resolved the matter of stat() ages ago
Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
> > Andrew Dunstan wrote:
> >
> >> I'm confused. There is a Cygwin member of buildfarm, working quite
> >> happily. Can you point me to the exact patch in question, please? I
> >> thought we resolved the matter of stat() ages ago.
> >>
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I'm confused. There is a Cygwin member of buildfarm, working quite
happily. Can you point me to the exact patch in question, please? I
thought we resolved the matter of stat() ages ago.
http://archives.postgresql.org/message-id/4865F707.
Andrew Dunstan wrote:
>
> I'm confused. There is a Cygwin member of buildfarm, working quite
> happily. Can you point me to the exact patch in question, please? I
> thought we resolved the matter of stat() ages ago.
http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at
--
Alv
I'm confused. There is a Cygwin member of buildfarm, working quite
happily. Can you point me to the exact patch in question, please? I
thought we resolved the matter of stat() ages ago.
cheers
andrew
Bruce Momjian wrote:
If we have no plan to apply this patch, do we need to remove Cygwin a
If we have no plan to apply this patch, do we need to remove Cygwin as a
supported platform?
---
Bruce Momjian wrote:
>
> Where are we on this? The patch was not acceptable for several reasons;
> for one:
>
> > And finall
Where are we on this? The patch was not acceptable for several reasons;
for one:
> 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 win3
Where are we on this patch?
---
Reini Urban wrote:
> Dave Page schrieb:
> > On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> >> Yes.
> >>
> >> As in the cygwin build does build. Nobody really has
Andrew Dunstan schrieb:
Magnus Hagander wrote:
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.
AIUI, only the gssapi stuff is broken. Most users are n
Magnus Hagander wrote:
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.
AIUI, only the gssapi stuff is broken. Most users are not likely to want
it o
Magnus Hagander schrieb:
Reini Urban wrote:
Dave Page schrieb:
On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <[EMAIL PROTECTED]>
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
Magnus Hagander wrote:
> > 8.3.x not because the new SSPI doesn't work yet.
> > 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
Reini Urban wrote:
> Dave Page schrieb:
>> On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <[EMAIL PROTECTED]>
>> 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 th
Dave Page schrieb:
On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <[EMAIL PROTECTED]> 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 anywa
Magnus Hagander wrote:
More to the point: I thought this had been tested. I will test it today
so we can put this whole thread to rest.
IIRC it was only tested insofar that it doesn't actually break. Not if
it returns proper results.
I have tested it using the suggested script (corr
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> Kenneth Marshall wrote:
>>
>>> One motivation for keeping it working on Cygwin, is that in some
>>> environments it is not allowed to install native Windows apps but
>>> they allow the use of the Cygwin environment. Of course if it takes
>>>
Magnus Hagander wrote:
Kenneth Marshall wrote:
One motivation for keeping it working on Cygwin, is that in some
environments it is not allowed to install native Windows apps but
they allow the use of the Cygwin environment. Of course if it takes
too many resources to support, then dropping
The case I am referring to has a "developer" clause that allows
Cygwin applications to be used for development only. I agree that
the policy is odd.
Ken
On Tue, Jun 24, 2008 at 02:35:50PM +0200, Magnus Hagander wrote:
> Kenneth Marshall wrote:
> > One motivation for keeping it working on Cygwin,
Kenneth Marshall wrote:
> One motivation for keeping it working on Cygwin, is that in some
> environments it is not allowed to install native Windows apps but
> they allow the use of the Cygwin environment. Of course if it takes
> too many resources to support, then dropping support would be an
> o
One motivation for keeping it working on Cygwin, is that in some
environments it is not allowed to install native Windows apps but
they allow the use of the Cygwin environment. Of course if it takes
too many resources to support, then dropping support would be an
option. I would check this for you,
On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <[EMAIL PROTECTED]> 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 mostl
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 c
Magnus, was this fixed/resolved?
---
Magnus Hagander wrote:
> It seems my fix for stat() broke cygwin, because it doesn't have
> dosmaperr() available. The way I see it there are two ways to fix this:
>
> 1) Don't apply the
Magnus Hagander <[EMAIL PROTECTED]> writes:
> It seems my fix for stat() broke cygwin, because it doesn't have
> dosmaperr() available.
Are you sure you aren't just missing an #include? The other places
where we call _dosmaperr don't seem to be protected by anything more
than #ifdef WIN32.
It seems my fix for stat() broke cygwin, because it doesn't have
dosmaperr() available. The way I see it there are two ways to fix this:
1) Don't apply the stat fix for cygwin.
2) Make our dosmaperr() function be used on cygwin.
I don't know if the fix is actually needed on cygwin. Can someone
27 matches
Mail list logo
