[OE-core] Proposed Multilib Implementation Brainstorming

Tom Rini tom_rini at mentor.com
Wed Apr 6 18:39:41 UTC 2011


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 at 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




More information about the Openembedded-core mailing list