Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Proposed Multilib Implementation Brainstorming
Date: Wed, 6 Apr 2011 11:39:41 -0700	[thread overview]
Message-ID: <4D9CB36D.5060406@mentor.com> (raw)
In-Reply-To: <51BF8F9A-3607-4DBF-9A6C-03E2FC1BD284@windriver.com>

On 04/06/2011 11:26 AM, Hatle, Mark wrote:
> A few comments to the original proposal below...
> 
> 
> 
> On Apr 5, 2011, at 2:24 PM, "Richard Purdie"
> <richard.purdie@linuxfoundation.org> wrote:
[snip]
>> and all the multilib class would need to do is to manipulation of 
>> variables including OVERRIDES in a similar way to native.bbclass
>> with the complication of handling the parameter.
>> 
> 
> One of the complications though is deciding what packages to build
> for which multilibs.  We will need a way to say the default system
> libraries and components should be say 32-bit.  But I need this one
> component to be 64-bit....

To be clear (and I think you agree), it also needs to be vice-versa
(64bit except...) and rather arbitrary on what recipes get which treatment.

>> The toolchain bootstrap process would become a little complicated
>> by this. We'll need to be able to iterate over the list of
>> multilibs and configure the compiler with a configuration
>> appropriate to the multilibs requested. The compiler should then
>> take care of generating a suitable libgcc for each multilib. Where
>> the compiler currently depends on virtual/libc-initial, we'll need
>> with a function called to generate the dependecies so for example:
>> "virtual/libc virtual/libc-initial-lib32"
>> 
> 
> I think the toolchain bootstrap is a place where the implementation
> of the toolchain can make this easier or MUCH harder.  In the
> environments I am used to using (code sorcery based toolchain) its a
> single binary that enables the user to use many different multilibs.
> However, this is likely not the best/easiest approach for source
> based toolchain builds.  It's much easier for use to just iteratively
> build toolchains for each multlib.  Using unique filenames can make
> this fairly easy to implement with minimal changes to the recipes.
> 
> Using something more complex like the CS toolchains, you can do
> simply by creating specific wrappers that call the base common
> toolchain with the right parameters to switch the multlib settings..

Putting my community hat on, why not replicate what the CS folks do?
Even with sstate and the yocto 1.1 goal of quicker builds, no one likes
how long the toolchain bottleneck is.

-- 
Tom Rini
Mentor Graphics Corporation



  reply	other threads:[~2011-04-06 18:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 11:02 Proposed Multilib Implementation Brainstorming Richard Purdie
2011-04-05 23:28 ` Jeremy Puhlman
2011-04-06 18:53   ` Richard Purdie
2011-04-06  7:08 ` Esben Haabendal
2011-04-06 12:05   ` [poky] " Richard Purdie
2011-04-06 12:16     ` Esben Haabendal
2011-04-06 13:06       ` Richard Purdie
2011-04-06 13:21         ` Esben Haabendal
2011-04-06 14:19           ` Richard Purdie
2011-04-06 16:38             ` Esben Haabendal
2011-04-06 18:01     ` Hatle, Mark
2011-04-06 20:54       ` Esben Haabendal
2011-04-06 20:55       ` Esben Haabendal
2011-04-06  7:16 ` Koen Kooi
2011-04-06  8:47 ` Frans Meulenbroeks
2011-04-06 14:29   ` Richard Purdie
2011-04-06 18:06     ` [poky] " Hatle, Mark
2011-04-06 18:25   ` Tom Rini
2011-04-07  6:10     ` Koen Kooi
2011-04-06 18:26 ` Hatle, Mark
2011-04-06 18:39   ` Tom Rini [this message]
2011-04-07 15:36 ` [poky] " Colin Walters
2011-04-07 16:10   ` Hatle, Mark
2011-04-07 16:53     ` Colin Walters
2011-04-07 17:04       ` Hatle, Mark
2011-04-07 17:10         ` Hatle, Mark
2011-04-07 17:07       ` Koen Kooi

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=4D9CB36D.5060406@mentor.com \
    --to=tom_rini@mentor.com \
    --cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox