[oe] building an SDK with an externally provided toolchain
Denys Dmytriyenko
denis at denix.org
Fri Apr 30 20:06:52 UTC 2010
On Thu, Apr 29, 2010 at 11:33:33AM -0700, C Michael Sundius wrote:
> Denys,
>
> in your comment in the thread:
>
> Re: [oe] [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of
> TARGET_SYS
>
> > Ok, you asked for a comment, I'll give you two :)
> >
> > 1. In Arago I have a way to overwrite SDKPATH from the command line when
> > building a specific SDK/toolchain. So, I can do what you suggest, but...
> >
> > 2. My SDKs are currently not machine-specific, moreover, they don't have
> > the
> > cross-compile tools in them (i.e. no toolchain part), as Arago uses
> > external
> > CodeSourcery toolchain for that. The only cross-tools I have in my SDKs are
> > those, which are missing from CS - i.e. libtool, pkgconfig, opkg,
> > qt4e-tools
> > etc. But I still build 2 versions of SDK - armv5te and armv7a.
> >
> I am in a similar predicament where we have to use a tool-chain provided to
> us prior to the adoption of OE. As a result, we've hacked up our own
> external-toolchain recipe to copy the libs and headers into the staging dir,
> but do not have a real cross-compile. we just add the path for the actual
> tools. We also would like to provide an SDK of our libraries separately from
> the toolchain that we deliver to our SDK customers.
>
> my question is, how do you build your sdk. since our SDK_PATH is not where
> our toolchain is the sdk.bbclass points ${prefix} to /usr/local (which does
> not contain our toolchain) thus much of the makery reverts to looking in
> /usr/include for headers which of course casuse the build to break..
>
> do you keep your external toolchain from CS in your SDK_PATH or somewhere
> else?
>
> you seem to allude to the fact that you did some magic to overrite the
> SDKPATH in certain circumstances.. I didn't see it in your code.
The trick is that meta-toolchain recipe does not build any target packages and
expects them to be already available in deploy - it only opkg-installs them.
Thus, it's safe to overwrite SDK_PATH when building/assembling the SDK. I have
a python code in my local.conf (argh, my local.conf already looks like a
distro.conf) where I set SDK_PATH to point to CSL for normal builds; or set it
with the directory (provided through a separate variable set on the command
line) where I want the SDK installed, when building said SDK:
SDK_PATH = "${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1), bb.data.getVar('META_SDK_PATH', d, 1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}"
I.e. if META_SDK_PATH is set, assume we are building SDK and set SDK_PATH to
the root of our SDK, otherwise set it to TOOLCHAIN_PATH, which is CSL. I also
set TOOLCHAIN_PATH in addition to SDK_PATH in the environment-setup script,
generated by meta-toolchain.bb
Then I make builds like this:
$ MACHINE=omap3evm bitbake arago-image
$ META_SDK_PATH=/opt/arago-sdk MACHINE=omap3evm bitbake meta-toolchain-arago
Feel free to poke around in the Arago repository:
http://arago-project.org/git/arago.git
--
Denys
More information about the Openembedded-devel
mailing list