All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Issue with (gcc-cross-|glibc-)initial and packaged staging
Date: Tue, 9 Mar 2010 10:42:51 -0800	[thread overview]
Message-ID: <19c1b8a91003091042s542dbfdl32d3d0f009753df2@mail.gmail.com> (raw)
In-Reply-To: <1268134848.32439.12.camel@hydra>

On Tue, Mar 9, 2010 at 3:40 AM, Thomas Horsten
<thomas.horsten@citrix.com> wrote:
> I've spotted a rather annoying interim build failure but I'm not sure
> how to best tackle the situation.
>
> For example, gcc-cross-initial and gcc-cross install some of the same
> files in staging. Normally this doesn't matter, since gcc-cross
> overwrites the earlier ones installed by -initial, but when using
> packaged staging and many threads (BBTHREADS=10 for example), it
> sometimes happens that the pstaging packages for gcc-cross-initial and
> gcc-cross get installed into staging in the wrong order (or at the same
> time in two different threads), resulting in all builds after that
> failing due to undefined references in the lib files from -initial.

toolchain build happens in a sequence due to catch 22 it has to get
itself bootstrapped.
In a better world when staging is always packaged then gcc-initial
would create packages
which would be obsoleted by gcc-cross.

>
> Whether this happens or not is a timing dependent issue, so it's
> sometimes hard to reproduce.
>
> Any ideas how to solve this issue? I'm thinking that after gcc-cross
> (and glibc-cross) have been built there is no need to depend on the
> -initial packages any more.

yes but for that you need to have the notion of toolchain is not being
build from scratch and in
other case when you have already bootstrapped it. This state
information needs to be saved somehow
obsoleting package feature in dpkg or bitbake would help in this
regard when it sees that gcc-cross is
already installed it would replace all gcc-cross-initial and
gcc-cross-intermediate references with gcc-cross


 Another option would be to install them with
> different paths.

I think if there

>
> Thomas
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



  reply	other threads:[~2010-03-09 18:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 11:40 Issue with (gcc-cross-|glibc-)initial and packaged staging Thomas Horsten
2010-03-09 18:42 ` Khem Raj [this message]
2010-03-09 20:07 ` Tom Rini
2010-03-09 21:05   ` Denys Dmytriyenko
2010-03-09 22:16     ` Chris Larson

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=19c1b8a91003091042s542dbfdl32d3d0f009753df2@mail.gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /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.