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