[OE-core] multilib theory & practice

Richard Purdie richard.purdie at linuxfoundation.org
Mon Aug 8 12:58:30 UTC 2011

On Sat, 2011-08-06 at 15:56 -0500, Kumar Gala wrote:
> I'm looking at trying to get multilib working for powerpc.  However
> I'm a bit lost in how this is suppose to work from a few different
> perspectives:
> 1. from user perspective (I'm starting with a 64-bit build in /lib64 and adding 32-bit that would be in /lib):
> (i've added in local/conf):
> require conf/multilib.conf
> MULTILIBS = "multilib:lib"
> DEFAULTTUNE_virtclass-multilib-lib = "powerpc"

Rather than use the identifier "lib", I'd use an identifier like "lib32"
which is unlikely to be found in a recipe name. Therefore something

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "powerpc"

> What should this end up producing?  Do I get a 32-bit set of libs built automatically?  What else do I need to do?

This will enable a number of other built targets such as "lib32-bash".
You can also construct images that are mixtures of the various multilibs
(e.g. install both openssl and lib32-openssl).

> 2. From a infrastructure point of view:
> * Do have a single compiler that is multi-arch or 2 compilers? (not sure how the x86_64 toolchain works today)

At this point we've gone for 2 compilers. This was a conscious choice to
avoid additional complexity and allow us to get the core functionality
working. We can support merged toolchains at a future date with
appropriate toolchain configuration and ASSUME_PROVIDED declarations.

> * what areas should I investigate that might need tweaking that are arch specific?

There should be very little beyond the places you've already changed
that should need tweaking. The only issues may be due to this being
very new code.

> * should I see different task names for the new multilib builds? (or the 32-bit specific builds?)

multilib.conf lists the recipes that will become multilib enabled. I've
just merged a patch to extend this list to include the various ones that
have been tested. The ultimate plan is not to require that list and its
just a transition point.



More information about the Openembedded-core mailing list