This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/63827] parallel make in libjava broken at r217383


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827

Jack Howarth <howarth.at.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth.at.gcc at gmail dot com

--- Comment #15 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
(In reply to Jack Howarth from comment #5)
> This is extremely reproducible at r217383 on darwin and no other breakage in
> the parallel make has been seen this week prior to this commit. The
> accumulated error messages in the failing build are...
> 
> make[3]: *** read jobs pipe: No such file or directory.  Stop.
> make[3]: *** Waiting for unfinished jobs....
> ...
> ake[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/
> libjava'
> Makefile:17122: recipe for target 'all-target-libjava' failed
> make[1]: *** [all-target-libjava] Error 2
> make[1]: Leaving directory
> '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
> Makefile:20722: recipe for target 'bootstrap' failed
> make: *** [bootstrap] Error 2
> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 16!
> 
> It looks like the failure occurs when the java classes are being compiled.
> Can we revert r217383 until the flaw in its handling of the parallel make is
> resolved? Having to build gcc serially is very painful.

This issue has reappeared OS X 10.11 for make 4.1 built with NLS support when
executed under the fink package manager using the system perl. The cause
appears to be the indirect linkage of the CoreFoundation framework via libintl.
The CoreFoundation frameworks sources don't contain any EINTR handling for
interruptible system calls like read(), etc so there will be potential race
conditions for programs using fork()/exec() like make.

radr://23248551 "The CoreFoundation framework and associated libraries aren't
fork()/exec() safe"


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]