On Sun, Mar 15, 2020 at 3:40 PM Khem Raj <[email protected]> wrote: > 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 :/.
I've heard reports of this still being an issue with latest OE 3.1 when -j is set high enough, without any -l options in EXTRA_OEMAKE (so Khem's workaround to over-ride -l doesn't help). Disabling PARALLEL_MAKE completely might be the best workaround for now until we understand the real root cause.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137585): https://lists.openembedded.org/g/openembedded-core/message/137585 Mute This Topic: https://lists.openembedded.org/mt/72395836/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/leave/8023207/1426099254/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
