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 . . .
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto