From: David Finnie <david.finnie68@gmail.com>
To: cygwin@cygwin.com
Subject: Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages
Date: Wed, 01 Jan 2020 22:32:00 -0000 [thread overview]
Message-ID: <93562f34-3a14-0c10-cb57-1ae861307d82@gmail.com> (raw)
In-Reply-To: <d24aa066-ab3d-9ff0-215a-0a1ed1ec2e5d@cornell.edu>
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) specified, some of the sub-makes fail with "Resource
>> temporarily unavailable" errors. In all cases, this has been when make is
>> starting a shell (i.e. $(shell ...) ) to help with setting up some of the
>> variables required in the make processing. The failure, however, occurs in
>> different places in the make files used (the make spawns several sub-makes).
> Does this happen with every parallel make, or is it one specific program that
> you're building? If the latter, can you give a detailed recipe so that others
> can try to reproduce the problem?
It's happening consistently across a bunch of libraries and executables
that I build (with a series of invocations of make). While each of those
builds has their own Makefile, each of them includes a common set of
makefiles that does the vast majority of the work, so I guess you could
say that it really is just isolated (as far as I can tell), to one build
environment. The build is not of open source software - it is for
software created by the company I work for, so unfortunately I can't
share all of the source code etc., but I can certainly give details of
what we're doing.
The make builds a cross-platform set of products, and so invokes both
Windows native compilers, and also cross compilers for the other
platforms (Linux, and HPE NonStop). So there are many tools being
invoked simultaneously.
Keep in mind, though, that this has been working perfectly for me for
over a decade. I will say that I did run into the need to run rebase
after upgrading cygwin many years ago, but that fixed the issue for me
immediately. Not so this time, and there has been nothing else changed
in my environment. I actually ran the build successfully just minutes
before upgrading the cygwin packages, and then it failed immediately
after that.
I have not tried building for any other product. I might try that.
> Have you tried reverting to cygwin-3.0.7-1?
No, I haven't - I'll try that now. Thanks.
>
> The only thing that jumps out at me from your cygcheck output is that your PATH
> is very long. I don't know if that's relevant, but you might try cutting it
> down before running make.
I did try changing PATH to a much smaller value
(/bin:/usr/bin:/usr/local/bin) but I still got exactly the same
behaviour :-( A good thing to try, though.
I'll see how I go after downgrading cygwin.
Thanks again.
Dave
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next parent reply other threads:[~2020-01-01 22:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6d43c714-c4ba-4f0c-9913-cb8453129c85@gmail.com>
[not found] ` <d24aa066-ab3d-9ff0-215a-0a1ed1ec2e5d@cornell.edu>
2020-01-01 22:32 ` David Finnie [this message]
2020-01-01 23:43 ` David Finnie
2020-01-02 3:02 ` Ken Brown
2020-01-02 21:58 ` Peter Dons Tychsen
2020-01-02 22:29 ` David Finnie
2020-01-02 22:40 ` Ken Brown
2020-02-05 21:46 ` Peter Dons Tychsen
2020-02-05 22:07 ` Ken Brown
2020-02-06 0:07 ` Takashi Yano
2020-02-05 22:18 ` David Finnie
2020-02-05 22:31 ` Ken Brown
2020-02-05 23:07 ` David Finnie
2020-02-05 23:35 ` Ken Brown
2020-02-07 18:13 ` Brian Inglis
2020-02-07 21:44 ` David Finnie
2020-02-10 20:58 ` Peter Dons Tychsen
2020-02-10 21:34 ` David Finnie
2020-02-11 2:21 ` Takashi Yano
2020-02-11 10:38 ` Peter Dons Tychsen
2020-02-11 10:40 ` Peter Dons Tychsen
2020-02-11 13:16 ` Takashi Yano
2020-02-11 14:21 ` Ken Brown
2020-02-12 14:40 ` Takashi Yano
2020-02-11 21:31 ` Peter Dons Tychsen
2020-02-12 2:25 ` Takashi Yano
2020-02-12 7:50 ` Corinna Vinschen
[not found] ` <20200212112411.32f05ee5ce2c1401bd076746@nifty.ne.jp>
[not found] ` <3971cde6277a16cb04ac25067b4478b9cfbfa319.camel@dontech.dk>
2020-02-13 4:14 ` Takashi Yano
2020-02-13 21:42 ` Peter Dons Tychsen
2020-02-14 1:25 ` Takashi Yano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=93562f34-3a14-0c10-cb57-1ae861307d82@gmail.com \
--to=david.finnie68@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).