<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 15, 2020 at 3:25 PM Richard Purdie &lt;<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 2020-03-15 at 15:23 -0700, Khem Raj wrote:<br>
&gt; On Sun, Mar 15, 2020 at 3:14 PM Richard Purdie<br>
&gt; &lt;<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; On Sat, 2020-03-14 at 21:29 -0700, Khem Raj wrote:<br>
&gt; &gt; &gt; In some cases, we run into parallel build failures where<br>
&gt; &gt; &gt; BUILT_SOURCES<br>
&gt; &gt; &gt; is skipped, as a result required header files are not generated and<br>
&gt; &gt; &gt; the<br>
&gt; &gt; &gt; build fails with missing header errors like<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h:<br>
&gt; &gt; &gt; No such file or directory<br>
&gt; &gt; &gt;  #include &quot;uniwidth.h&quot;<br>
&gt; &gt; &gt;           ^~~~~~~~~~~~<br>
&gt; &gt; &gt; compilation terminated.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; BUILT_SOURCES should be built automatically with `make all` [1]<br>
&gt; &gt; &gt; therefore<br>
&gt; &gt; &gt; ensure that make is invoked with `all` target<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; bison-native parallel build fails when -l&lt;n&gt; is passed globally from<br>
&gt; &gt; &gt; build environment, errors like below due to race starts to show up<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Therefore removes a previous load limit if set<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; [1]<br>
&gt; &gt; &gt; <a href="https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example" rel="noreferrer" target="_blank">https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example</a><br>
&gt; &gt; <br>
&gt; &gt; I&#39;m not sure I understand this. We&#39;ve seen a failure on our ubuntu1604<br>
&gt; &gt; performance tester which I think is the same bug as this. The<br>
&gt; &gt; environment on that machine doesn&#39;t change, so how/where is this -l<br>
&gt; &gt; option coming from?<br>
&gt; &gt; <br>
&gt; <br>
&gt; From custom distro global settings for EXTRA_OEMAKE<br>
&gt; <br>
&gt; &gt; I suspect there is some issue we&#39;re not quite getting to still :(<br>
&gt; &gt; <br>
&gt;  its well reproducible now with -j and -l together on our builders, From what<br>
&gt; I see in makefiles bison is doing right thing in using BUILT_SOURCES so<br>
&gt; I suspect it could be make acting in a certain way when those options<br>
&gt; are present.<br>
&gt; <br>
&gt; our custom settings use -l options globally in EXTRA_OEMAKE<br>
&gt; this is to let machines with certain configurations build when machines are<br>
&gt; shared, we don&#39;t want a given build to use all resources on box. Yes one<br>
&gt; could say why not do something else to limit the resources build uses but<br>
&gt; this is a global setting that works well<br>
&gt; <br>
&gt; This patch just ensures that any -l setting passed from environment is<br>
&gt; cleaned up and reset. So for general case it will be a noop.<br>
<br>
Ok, that explains your failure but not the one on our performance<br>
testing worker :/.</blockquote><div dir="auto"><br></div><div dir="auto">What errors do you see on perf testing worker is it exactly same ?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
</blockquote></div></div>