[OE-core] [poky] Proposed Multilib Implementation Brainstorming

Hatle, Mark mark.hatle at windriver.com
Wed Apr 6 18:06:14 UTC 2011





On Apr 6, 2011, at 7:29 AM, "Richard Purdie" <richard.purdie at linuxfoundation.org> wrote:

> On Wed, 2011-04-06 at 10:47 +0200, Frans Meulenbroeks wrote:
>> I think most embedded systems would only use one lib. To take your
>> lib/lib64 example:
>> If I am developing for an embedded system I know whether it will run
>> as 32 or 64 bit, so there is no need to have both.
> 
> I agree that this is the most common usecase and that remains unchanged.
> 

I'd like to stress that existing use-case behavior (non multilib) is imperative to keep the same as we have today.  Multilib is a specialized use case that covers large enough space that it needs to be supported.

>> multilib has its merits when it comes to supporting multiple hardware systems.
>> However as in the embedded world one is typically targeting a specific
>> hardware configuration.
>> (actually I don't recall having seen requests for multilib on the ML
>> before, although I could have missed it).
> 
> These have been requests I've received verbally in general but you'll
> see from the replies on the mailing list, Montavista is interested, Koen
> is as are a number of others.
> 

I'll add Wind River has customers that directly need this functionality.  Many of their products are similar to specialized servers, but really are embedded.

>> Also I'm somewhat worried by the actual complexity this adds (to the
>> build process and the recipes, and timewise probably also to the
>> bootstrap process as additional packages have to be built).
>> 
>> Not sure if that is a desirable route forward, but if we (we as in OE
>> members + developers) feel that OE should go that way, I would
>> sugggest to have a way to opt-in or opt-out
> 
> Multilib will be opt-in. Things will operate just as they do today
> unless you specify you want a multilib configuration.
> 
> Cheers,
> 
> Richard
> 
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky




More information about the Openembedded-core mailing list