3 ms·
If you find yourself wrestling with this in the future, you might try experimenting with Yocto's SDK generation capabilities. Most image recipes have a 'populat
by nrclark 7y ago
If you find yourself wrestling with this in the future, you might try experimenting with Yocto's SDK generation capabilities. Most image recipes have a 'populate_sdk' task that will generate a self-extracting shell script that includes a full cross-compilation toolchain and a set of libraries for the target. You can also add custom components to the SDK very easily.
Our CI system generates the SDK along with every build of our Yocto image. Another CI job grabs the SDK and uses it for some out-of-tree compilation work. It's very straightforward to automate that way.
- m0zg 7y agoYes, and that shell script can't be simply unpacked. It has to run, and when it does, it rewrites paths to libs that the toolchain needs to pull in so that they point to the correct installed locations. In contrast, Buildroot toolchains require that only relative paths match, and do not require that absolute paths are embedded into the binaries and *.so's.
- nrclark 7y agoYou're right, of course - I wouldn't say that Yocto's SDK generator is perfect. But it does work fine, and you can install the SDK anywhere you want. From a CI system's point of view, what's the logical difference between [tar xf toolchain.tar.gz] and [./install_sdk.sh -yd .]?