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

Colin Walters walters at verbum.org
Thu Apr 7 15:36:05 UTC 2011


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?)

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.

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.

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.




More information about the Openembedded-core mailing list