bootcycle builds x86_64-linux-gnu?

[Matthias Klose]

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.