Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: multilib theory & practice
Date: Mon, 08 Aug 2011 13:58:30 +0100	[thread overview]
Message-ID: <1312808310.14274.187.camel@rex> (raw)
In-Reply-To: <F5D4B029-50F1-47E1-934C-8918DF2624F5@kernel.crashing.org>

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






  parent reply	other threads:[~2011-08-08 13:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-06 20:56 multilib theory & practice Kumar Gala
2011-08-07 16:50 ` Kumar Gala
2011-08-08 12:59   ` Richard Purdie
2011-08-08 12:58 ` Richard Purdie [this message]
2011-08-08 14:32   ` Kumar Gala
2011-08-08 14:53     ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1312808310.14274.187.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=galak@kernel.crashing.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox