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
next prev 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