[OE-core] [PATCH] bison: Reset load average settings if specified in environment

Khem Raj raj.khem at gmail.com
Sun Mar 15 22:40:33 UTC 2020


On Sun, Mar 15, 2020 at 3:25 PM Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Sun, 2020-03-15 at 15:23 -0700, Khem Raj wrote:
> > On Sun, Mar 15, 2020 at 3:14 PM Richard Purdie
> > <richard.purdie at linuxfoundation.org> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200315/5aa5c32a/attachment.html>


More information about the Openembedded-core mailing list