On Mon, Sep 02, 2013 at 06:40:01PM -0400, David Boyce wrote: > On Mon, Sep 2, 2013 at 4:19 PM, Chris Faylor wrote: > > *There is one know issue with fork where dlls in forked processes > don't > > load at the right address and cause cygwin errors. That is usually > fixed by running the autorebase program. > > And it is that issue to which I refer. One of my co-workers claims to > have an STC which, using make -j, can reliably reproduce fork failures > even in 1.7.24 (or at least some very recent version employing > autorebase). Possibly he's wrong, or possibly it's BLODA, but even if > it's BLODA a spawn-based version would likely not suffer from the same > problem. If your claim is that fork should be expected to work 100% of > the time in a fully rebased install (which is what I thought and what I > told him when this first came up) I'll be happy to try and get ahold of > the test case and send it in. > And if a command-line flag has been agreed upon as Eli says, that's > good enough for me. In fact any answer is good enough for me as long as > the resulting make.exe works reliably with -j at large scale factors.
I'm interested in test cases which show fork failing for which rebase doesn't fix the problem unless it actually is a third party app causing interference. If there are third-party apps interfering with Cygwin then they can also influence spawn and other operations. It's not just fork that's affected. In case anyone is wondering: http://cygwin.com/acronyms/#BLODA cgf _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
