Re: multilib theory & practice

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2011-08-08 at 09:32 -0500, Kumar Gala wrote:
> On Aug 8, 2011, at 7:58 AM, Richard Purdie wrote:
> > 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
> > like:
> > 
> > require conf/multilib.conf
> > MULTILIBS = "multilib:lib32"
> > DEFAULTTUNE_virtclass-multilib-lib32 = "powerpc"
> 
> is 'lib32' utilized anywhere else or just to match these things
> together?  Just want to be clear that I'd expect 32-bit libraries to
> be in /lib/

The actual baselib comes from:

BASE_LIB_tune-powerpc = "lib"

i.e. from the tune you selected so it would be lib unless you overrode
this value. The "lib32" is just used as an identifier in this scenario.

> >> 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).
> 
> What would I expect w/regards to RPM or ipk's that are created?  How
> does one tell the 32-bit vs 64-bit?

It depends on the package backend and what its capabilities are.

Offhand I think we settled on rpms having the same name but being placed
in a different directory and have the package architecture changed. The
names of ipks are changed to include the "lib32-" prefix.

> >> 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 would they be called or how are they distinguished?

They're installed into different paths and the lib32- prefix is also
used for the different targets.

> >> * 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.
> 
> I feel like I tried 'enabling' multilib on ppc and didn't see anything new built for the 32-bit libs.

Did you try something like "bitbake lib32-bash" though?

Cheers,

Richard