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: >>> >>> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...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-'/<<PKGBUILDDIR>>' failure-handler make< >>> make[5]: Leaving directory '/<<PKGBUILDDIR>>' >>> 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.
