All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Giulio Benetti <giulio.benetti@benettiengineering.com>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>,
	Eric Le Bihan <eric.le.bihan.dev@free.fr>,
	Herve Codina <herve.codina@bootlin.com>,
	Matthew Weber <matthew.weber@rockwellcollins.com>,
	Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>,
	Fabrice Fontaine <fontaine.fabrice@gmail.com>,
	buildroot@buildroot.org,
	Giulio Benetti <giulio.benetti@micronovasrl.com>,
	Adam Duskett <aduskett@gmail.com>
Subject: Re: [Buildroot] Analysis of build results for 2021-08-17
Date: Thu, 19 Aug 2021 15:28:52 +0200	[thread overview]
Message-ID: <20210819152852.760ec08d@windsurf> (raw)
In-Reply-To: <412e2832-62e5-8cbe-6a85-e797b3281978@benettiengineering.com>

Hello,

On Thu, 19 Aug 2021 00:24:06 +0200
Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:

> This waits for you to release new OpenRisc Bootlin toolchain. At 
> Buildroot level all OpenRisc patches we're covered(on gcc 11.1.0 too 
> from yesterday). So with that you should be able to create the new 
> Bootlin OpenRisc Toolchain that will also enable -mcmodel=large for 
> libgeos and protobuf, basically they will be both re-enabled for 
> OpenRisc :-)

ACK, thanks for confirming.

> >>      or1k     |            unknown             | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |  
> > 
> > Top-level parallel build, no idea what the issue is.  
> 
> Can somebody point me some idea on how to approach Top-level parallel 
> build debugging? I also have some udisks package failure due to that.
> I mean, now what I do is ./br_reproduce_build SHA1, then I CTRL-C and:
> # cd SHA1
> # cd output
> # make package-that-fails
> 
> But with Top-level I have more output-x, how can I reissue the command 
> and are there any trick to debug it?

I would go in two steps:

 (1) First see if you can reproduce without top-level parallel build,
     i.e you keep BR2_PER_PACKAGE_DIRECTORIES=y, but you do the build with
     "make". I am pretty sure that 95% of the issues will also be
     reproducible this way, and are more related to per-package
     directories than top-level parallel build.

 (2) If that doesn't allow to reproduce the issue, then you'll want to
     rebuild with "make -jX". However, here it would mean the issue is
     really with parallel build, so it's not because one build succeeds
     that another build won't fail: we might have race conditions that only
     rarely happen, just like the parallel build of individual packages. Of
     course, in principle with per-package directories, we are not supposed
     to have this kind of race conditions, but who knows what unforeseen
     issues still exist?

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

  parent reply	other threads:[~2021-08-19 13:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  6:57 [Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17 Thomas Petazzoni
2021-08-18 10:25 ` Thomas Petazzoni
2021-08-18 11:05   ` Yann E. MORIN
2021-08-18 20:18     ` Thomas Petazzoni
2021-08-18 21:04       ` Yann E. MORIN
2021-08-23 20:55         ` Arnout Vandecappelle
2021-08-23 22:06           ` Thomas Petazzoni
2021-08-23 22:16             ` Arnout Vandecappelle
2021-08-18 21:44 ` [Buildroot] Analysis of build " Thomas Petazzoni
2021-08-18 22:24   ` Giulio Benetti
2021-08-18 22:26     ` Giulio Benetti
2021-08-19  0:01     ` Giulio Benetti
2021-08-19 13:28     ` Thomas Petazzoni [this message]
2021-08-20 14:26       ` Giulio Benetti
2021-08-20 22:00         ` Giulio Benetti
2021-08-21 23:08     ` Giulio Benetti
2021-08-19  9:27   ` Arnout Vandecappelle
2021-08-19 13:24     ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210819152852.760ec08d@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=aduskett@gmail.com \
    --cc=bernd.kuhls@t-online.de \
    --cc=buildroot@buildroot.org \
    --cc=eric.le.bihan.dev@free.fr \
    --cc=fontaine.fabrice@gmail.com \
    --cc=giulio.benetti@benettiengineering.com \
    --cc=giulio.benetti@micronovasrl.com \
    --cc=gwenhael.goavec-merou@trabucayre.com \
    --cc=herve.codina@bootlin.com \
    --cc=matthew.weber@rockwellcollins.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.