bootcycle builds x86_64-linux-gnu? (original) (raw)

Matthias Klose doko at ubuntu.com
Mon Dec 10 18:05:00 UTC 2018

On 10.12.18 11:49, Magnus Ihse Bursie wrote:

On 2018-12-10 11:31, Severin Gehwolf wrote: On Mon, 2018-12-10 at 11:19 +0100, Magnus Ihse Bursie wrote: On 2018-12-09 11:58, Matthias Klose wrote:

On 06.12.18 22:03, Erik Joelsson wrote:

Nothing strange in there. Is it only printed once? I wouldn't be surprised if this got printed more than one time during a normal make execution (due to reloads caused by -include). If it is, then perhaps there is something different in a later print? no, it's only printed once. And it seems to be independent of the test-image target. just the bootcycle-images target is enough to trigger that [1]. Also not architecture specific for the hotspot targets. Builds without the bootcycle target succeed [2].

Anything else wrong with the configury in [1]? It's a bit hard to say. I'm reacting to "make -C build", maybe the -C does not play well with bootcycle builds? I don't think that's a very well tested combination, and bootcycle builds is really like running the build twice in different directories. But I don't know, it shouldn't affect things... You are also running with a very detailed log level, it hardly makes it easier to read the log. I recommend using "info,cmdlines" instead of "debug" unless actively debugging a hard-to-find issue. ... Found it! Erik's intuition was correct: ALLNAMEDTESTS >build coretools ctw1 ctw2 ctw3 [...snip...] gtest micro make-make-base make-java-compilation make-copy-files make-idea make-compile-commands make-make[5]: make-Leaving make-directory make-'/<>' failure-handler make<_ _make[5]: Leaving directory '/<>' make/Main.gmk:1088: *** target pattern contains no '%'.  Stop. So once again we're being bit by the make changedir message. And maybe that's triggered in a new way due to the -C? Try adding --no-print-directory to your top-level make invocation, as a workaround. We should probably send that as a flag to make, always. Wasn't this fixed with? https://bugs.openjdk.java.net/browse/JDK-8213736 Unless Matthias is running with an outdated source (Matthias: Are you?), I'm afraid that the solution in JDK-8213736 was not complete. :( The makefile bootstraping logic is quite hairy, and I'm sure there's ways to still trigger the same issue, but differently.

I'm basing these packages on the last tag, this one was jdk-12+23.

More information about the build-dev mailing list