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

[Hatle, Mark]

On Apr 7, 2011, at 8:36 AM, "Colin Walters" <walters at verbum.org> wrote:

> On Tue, Apr 5, 2011 at 7:02 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> One of the items on our post 1.0 schedule is multilib and we need a plan
>> of implementation. I've been thinking about this for a while and at
>> least have some ideas how some of the issues can be handled.
>> 
>> In case anyone isn't familiar with the idea of multilibs, the most
>> common example are x86 systems which have both 32 bit and 64 bit
>> libraries installed at the same time in /lib/ and /lib64/ directories or
>> similar and hence both types of binaries can be used.
> 
> I call this "rpm style" multilib.
> 
>> The number of libs isn't limited to two choices as for example the mips
>> platform has three choices which can be used in parallel. The x32 ABI
>> would mean three possible x86 options too.
> 
> I don't think there's any precedent in RPM for anything beyond 2 (is there?)
> 

RPM uses file 'colors' to handle the multilib conflict and installation policy.  The colors are defined as a bit field where so far only 3 bit are defined.  Elf 32, elf 64, and MIPS n32.

So we have a way to do more then three, currently MIPS64 n32 is the only architecture this is defined on.

> In this discussion we should be sure we're clear on the distinction
> between "multilib" and "multiarch".  Multilib's goal is simply
> parallel-installable libraries mainly; for the use case stated above,
> where you have a 64 bit system and want to run a 32 bit Unix
> application, or vice versa.
> 

I think definition may be an issue here.  When I speak of multilibs I am talking primarily about multiliple non-conflicting, ABI incompatible libraries being installed at the same time.  This is the ELF 32 and ELF 64 case where the items can't be linked together, but can be installed and jrun on the same machine.

The alternative is the case on ARM where we have one single ABI but multiple ways to implement the code.. Thumb, neon, vfp, etc being options.  We want to do this as well, but while related, I see it as a diffent use case.

> Multiarch is much more ambitious - it includes cross compilation for
> example (something that people keep thinking multilib was designed
> for, but it never was).
> 
> So are you proposing multilib or multiarch for OE?  It looks like
> multilib, but I want to be sure we're clear on the goal.
> 

Multilib, install of binaries that will execute natively on the machine.

> In your proposal, it looks like you're suggesting the libdir names are
> up to the image creator?  If we're doing something new *now* without
> any backwards compatibility concerns, we might consider using the
> Debian/Ubuntu scheme for libdirs.  This may come at the expense of
> having to patch RPM, but I'm not sure how hardcoded the lib/lib64
> paths are in the ecosystem; it may be pretty easy.

Lib dir names are already defined within the system configuration, but there hasn't been a lot of work to prove it's being used and is working properly.  (everyone uses /lib today...)

Rpm really doesn't care or pay attention to the path, it's the elf file type that matters...

> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky