[yocto] Creating a meta-layer for a third-party GCC-based binary tool-chain - how?

[Glenn Schmottlach]

I'm trying to create a meta-layer for a third-party GCC-based proprietary
tool-chain. I need to be able to select this tool-chain on a per-recipe
basis while other recipes may either the standard Yocto
native/cross-tool-chain. This proprietary tool chain is divided into a
host-tool part (where all the cross-tools are located, e.g.
arm-unknown-nto-qnx6.5.0-gcc/ar/g++ etc...) and the associated target
sysroot that includes common headers and target (arm, mips, ppc, sh4, x86)
specific libraries. This tool-chain on my system is sitting in /opt outside
of the Yocto environment and is not re-distributable in a third-party SDK
(e.g. you have to license it from the manufacturer and install it
separately).

I seem to have come across two approaches to this problem. One solution
appears to be recommended by the OE community and it is described here:

http://www.openembedded.org/wiki/Adding_a_secondary_toolchain

This approach *seems* to offer the ability to selectively (per recipe)
enable/disable a secondary tool-chain. What is not clear is whether Yocto
supports this approach.

The second approach seems to be the one used by Linaro and CodeSourcery and
involves setting the TCMODE/TCLIB variables and may be more extensive.
What's not clear is whether the Linaro/CodeSourcery tool-chain can
selectively be turned on/off per recipe.

I've done some prototyping with both approach but I've had mixed success .
. . partly due to my in-experience with BitBake/Yocto. So I hope someone
can take pity on me and answer a few questions:

1) Is the OE approach of adding a secondary tool-chain work-able under
Yocto? Is the Yocto (TCMODE/TCLIB) approach more acceptable (e.g.
recommended) and does it allow the recipe itself (or some other white/black
listing approach) to decide which recipes are compiled with the alternate
tool-chain? If so, how does a recipe specify the tool-chain that should be
used? It's not clear by examining the meta-layers provided by those
tool-chains.

2) Since my proprietary tool-chain has it's own sysroot outside Yocto, I
believe the recommended approach is to copy this sysroot into the a Yocto
generated sysroot. If so, where do I do that? Do create a second recipe to
do that? Is it done in the meta-toolchain  .conf files or .bbclass files?
How do I make sure these system files are copied to the Yocto sysroot
before building the recipes that depend on it?

3) What will be the name of the sysroot where I should copy the external
binary tool-chain to? I can't figure out who/how that name is generated and
used . . . is it based off the tool-chain prefix (e.g.
arm-unknown-nto-6.5.0)? Is it something I can specify?

4) The external tool-chain has a non-e/glibc based C library (it's
Dinkumware based). Do I have to do anything special to keep it from linking
against the one created/used by Yocto?

5) Ultimately, the target machine and OS is not Linux but very similar
(e.g. posix based). At this point I'm not concerned about building a
boot-able image but rather just building individual recipes and packing the
resulting libraries/applications into a convenient tarball (or opkg
archive). So I'm thinking I just need to specify a very rudimentary/simple
"machine" in order to specify the CPU architecture so the right external
cross-tool is selected. Is there any such meta-layer available . . . a very
minimal machine? I could accept a QEMU based machine (if necessary) because
the OS I'm targeting can be run under QEMU. Of course the question may be
whether I really need to specify a machine/distro for my use-case?

At this time, I just want to use my tool-chain meta-layer to help me
port/build/package several middle-ware and library components using an
external (non-distributable) binary tool-chain. In this sense, I'm only
using Yocto to do half of it's customary job which (usually) results in a
Linux image for a target.

This request for assistance is long. Any answers that could be provided
(even if they don't address all of my questions) would be extremely
helpful. Links to previous discussions would be useful as well.

Thanks for your time and consideration . . .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20130621/11a99eea/attachment.html>