On Thu, 13 Feb 2020 22:42:31 +0100
Peter Dons Tychsen wrote:
> On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote:
> > Could you please try latest snapshot?
> > https://cygwin.com/snapshots/
>
> The commit regarding use of kill() does the trick.
> It's a go from here :-).
>
> Thanks for all
Hi Takashi,
On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote:
> Could you please try latest snapshot?
> https://cygwin.com/snapshots/
The commit regarding use of kill() does the trick.
It's a go from here :-).
Thanks for all the help,
/pedro
--
Problem reports:
On Wed, 12 Feb 2020 11:54:02 +0100
Peter Dons Tychsen wrote:
> Hi Takashi,
>
> On Wed, 2020-02-12 at 11:24 +0900, Takashi Yano wrote:
> > My failure in pty code was that I used kill() in pty system
> > calls. kill() can be used check if the process is still alive
> > by passing signal number of 0
On Tue, 11 Feb 2020 09:21:32 -0500
Ken Brown wrote:
> On 2/11/2020 8:16 AM, Takashi Yano wrote:
> > On Tue, 11 Feb 2020 11:38:35 +0100
> > Peter Dons Tychsen wrote:
> >> On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
> >>> Is this the same as your problem?
> >>
> >> Yeah, it could be.
On Feb 12 11:24, Takashi Yano wrote:
> On Tue, 11 Feb 2020 22:31:12 +0100
> Peter Dons Tychsen wrote:
> > On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote:
> > > however, I found the real cause is that errno is accidentally set
> > > by kill() in pty system calls. That is, the problem is not
On Tue, 11 Feb 2020 22:31:12 +0100
Peter Dons Tychsen wrote:
> On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote:
> > however, I found the real cause is that errno is accidentally set
> > by kill() in pty system calls. That is, the problem is not in the
> > kill() itself but in usage of it.
Hi Takashi,
Thanks for your effort.
On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote:
> however, I found the real cause is that errno is accidentally set
> by kill() in pty system calls. That is, the problem is not in the
> kill() itself but in usage of it. Cygwin older than 3.1.0 does not
On 2/11/2020 8:16 AM, Takashi Yano wrote:
On Tue, 11 Feb 2020 11:38:35 +0100
Peter Dons Tychsen wrote:
On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
Is this the same as your problem?
Yeah, it could be. Could this result in fork error messages as we are
seeing all over the place?
On Tue, 11 Feb 2020 11:38:35 +0100
Peter Dons Tychsen wrote:
> On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
> > Is this the same as your problem?
>
> Yeah, it could be. Could this result in fork error messages as we are
> seeing all over the place?
No. Fork error is not seen in my
On Tue, 2020-02-11 at 11:38 +0100, Peter Dons Tychsen wrote:
> processes. And why did this work before?
And why does it work when running without minnty? How does that play
into this?
Thanks,
/pedro
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Hi Takashi,
Thanks for looking at this & your great work on Cygwin!
On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
> Is this the same as your problem?
Yeah, it could be. Could this result in fork error messages as we are
seeing all over the place?
> If so, it goes without stopping 1
On Mon, 10 Feb 2020 21:58:09 +0100
Peter Dons Tychsen wrote:
> 1) Put attached makefile somewhere
> 2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe
> and unzip it in same place.
> 3) Now run "make create"
> 4) Now run "make clean && make -j32". Try a couple of times.
>
>
On 11/02/2020 07:58, Peter Dons Tychsen wrote:
It seems to be related to the fact the is is spawning non-cygwin
programs. If i do the same test with normal GCC (default cygwin gcc)
then everything is fine.
That's great work, and I can confirm that it is the same in my
environment. Our
Hi all,
On Thu, 2020-02-06 at 09:18 +1100, David Finnie wrote:
> That would be awesome if you could create a small test case
OK, i put together a test-case:
1) Put attached makefile somewhere
2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe
and unzip it in same place.
3) Now
On 8/02/2020 05:13, Brian Inglis wrote:
DF's post immediately preceding that KB post at the start of*January* *was*
Brian, indeed. And, as I'm sure you're aware - given that you were
trawling through past posts - Ken already pulled me up on it, and since
then I haven't. It has been my
On 2020-02-05 16:35, Ken Brown wrote:
> On 2/5/2020 6:07 PM, David Finnie wrote:
>>> [Please don't top-post on this list. Thanks.]
>> What do you mean by top posting, then ? How was my post a top post ?
> It wasn't. I misread it. Sorry.
DF's post immediately preceding that KB post at the start
On Wed, 5 Feb 2020 17:07:38 -0500
Ken Brown wrote:
> That last issue is probably due to changes in
> /usr/bin/cygwin-console-helper.exe
> related to the new PTY code. So in addition to rewinding the DLL, you have
> to
> rewind cygwin-console-helper.
Indeed, cygwin-console-helper.exe was
On 2/5/2020 6:07 PM, David Finnie wrote:
[Please don't top-post on this list. Thanks.]
What do you mean by top posting, then ? How was my post a top post ?
It wasn't. I misread it. Sorry.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ:
[Please don't top-post on this list. Thanks.]
What do you mean by top posting, then ? How was my post a top post ?
Thanks.
Dave
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
[Please don't top-post on this list. Thanks.]
On 2/5/2020 5:18 PM, David Finnie wrote:
Hi Pedro,
I have started down the road of building cygwin, but did run into a
few issues so don't have a debuggable version yet. If you beat me to
it, please let me know. Thanks!
Any findings?
Hi Pedro,
I have started down the road of building cygwin, but did run into a
few issues so don't have a debuggable version yet. If you beat me to
it, please let me know. Thanks!
Any findings?
Unfortunately no, I did get a clean build, but "make install" following
it just created complete
On 2/5/2020 4:45 PM, Peter Dons Tychsen wrote:
Hi David & Co,
I have started down the road of building cygwin, but did run into a
few issues so don't have a debuggable version yet. If you beat me to
it, please let me know. Thanks!
Any findings?
I have found something interesting:
1) If i
Hi David & Co,
> I have started down the road of building cygwin, but did run into a
> few issues so don't have a debuggable version yet. If you beat me to
> it, please let me know. Thanks!
Any findings?
I have found something interesting:
1) If i run the terminal without mintty, the problem
[Please don't top-post on this list. Thanks.]
On 1/2/2020 5:29 PM, David Finnie wrote:
> Hi Pedro,
>
> That's good to hear confirmation.
>
> I have started down the road of building cygwin, but did run into a few
> issues so don't have a debuggable version yet. If you beat me to it,
> please
Hi Pedro,
That's good to hear confirmation.
I have started down the road of building cygwin, but did run into a few
issues so don't have a debuggable version yet. If you beat me to it,
please let me know. Thanks!
Dave
On Fri, 3 Jan. 2020, 08:58 Peter Dons Tychsen, wrote:
> Hi Cygwinners,
>
>
Hi Cygwinners,
On Thu, 2020-01-02 at 10:43 +1100, David Finnie wrote:
> I did as Ken suggested and reverted to 3.0.7-1. (Thanks, Ken !)
>
> That has fixed the issue for me, and the make it now running again
> at
> full speed. I forgot to mention that it did seem somewhat slower
> with
> the
On 1/1/2020 6:43 PM, David Finnie wrote:
> That strongly implies that there is an issue with changes made since then. I
> noticed that in fork.cc, at line 540, this new code exists:
>
> /* Do not attach to the child before it has successfully initialized.
> Otherwise we may wait
Hi all,
I did as Ken suggested and reverted to 3.0.7-1. (Thanks, Ken !)
That has fixed the issue for me, and the make it now running again at
full speed. I forgot to mention that it did seem somewhat slower with
the new version of cygwin.
That strongly implies that there is an issue with
Hi Ken,
Thanks for having a look at my issue.
On 1/01/2020 06:20, Ken Brown wrote:
On 12/30/2019 6:10 PM, David Finnie wrote:
I recently upgraded my cygwin64 installation to get latest packages.
After the install, if I run a fairly lengthy GNU make with multiple concurrent
jobs (-j option)
On 12/30/2019 6:10 PM, David Finnie wrote:
> I recently upgraded my cygwin64 installation to get latest packages.
>
> After the install, if I run a fairly lengthy GNU make with multiple
> concurrent
> jobs (-j option) specified, some of the sub-makes fail with "Resource
> temporarily
I recently upgraded my cygwin64 installation to get latest packages.
After the install, if I run a fairly lengthy GNU make with multiple
concurrent jobs (-j option) specified, some of the sub-makes fail with
"Resource temporarily unavailable" errors. In all cases, this has been
when make is
31 matches
Mail list logo
