multilib theory & practice

multilib theory & practice

[Kumar Gala]

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"

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

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)
* what areas should I investigate that might need tweaking that are arch specific?
* should I see different task names for the new multilib builds? (or the 32-bit specific builds?)

- k

Re: multilib theory & practice

[Kumar Gala]

On Aug 6, 2011, at 3:56 PM, 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"
> 
> What should this end up producing?  Do I get a 32-bit set of libs built automatically?  What else do I need to do?
> 
> 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)
> * what areas should I investigate that might need tweaking that are arch specific?
> * should I see different task names for the new multilib builds? (or the 32-bit specific builds?)

To add to this I'm wondering how we get proper eglibc for 32-bit, how we get proper gcc libs (libgcc, etc).

- k

Re: multilib theory & practice

[Richard Purdie]

On Sun, 2011-08-07 at 11:50 -0500, Kumar Gala wrote:
> On Aug 6, 2011, at 3:56 PM, 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"
> > 
> > What should this end up producing?  Do I get a 32-bit set of libs built automatically?  What else do I need to do?
> > 
> > 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)
> > * what areas should I investigate that might need tweaking that are arch specific?
> > * should I see different task names for the new multilib builds? (or the 32-bit specific builds?)
> 
> To add to this I'm wondering how we get proper eglibc for 32-bit, how we get proper gcc libs (libgcc, etc).

As per my reply, we currently treat this as two separate toolchains so
this makes this part of the problem very easy.

Cheers,

Richard

Re: multilib theory & practice

[Richard Purdie]

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"

> 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.

Cheers,

Richard

Re: multilib theory & practice

[Kumar Gala]

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/

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

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

>> * 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.

- k

Re: multilib theory & practice

[Richard Purdie]

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