This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/41337] [LTO] Parallel build failure
- From: "dmitrij.ledkov at ubuntu dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 17 Nov 2010 21:02:59 +0000
- Subject: [Bug bootstrap/41337] [LTO] Parallel build failure
- Auto-submitted: auto-generated
- References: <bug-41337-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41337
--- Comment #4 from Dima <dmitrij.ledkov at ubuntu dot com> 2010-11-17 21:02:58 UTC ---
(In reply to comment #3)
> If you encounter parallel build failures, please post exact revision that was
> built, configure command line, build system type, number of processors on the
> box, N argument in 'make -jN', and ideally also the likelihood (in precent)
> that the build fails, if it is not deterministic. Please also post the last
> 300 or so lines of build output, and maybe check whether it always fails in the
> same spot.
>
I'm building a cross-compiler: build/host = gnu-linux; target =
i686-w64-mingw32. I've been using gcc-4.4 branch this whole week (will test
again with trunk when I have time). It is fully deterministic (100% fail rate
at the same spot) when I supply --with-build-libsubdir pointing to the
$prefix/$target-triplet/lib. But the mentioned value for --with-build-libsubdir
option is bogus and doesn't make sense.
> It is not too hard to pinpoint parallel build failures but only if there is
> enough data available.
I no longer believe my error was to do with parallel make, it was the error
between the keyboard and the chair =) in other words "pilot error".
If someone else will come across with
> make[1]: *** No rule to make target `build/gencondmd', needed by `s-condmd'
Check your config and make sure it is sane =)