3 ms·

I wish they'd generate toolchains I didn't have to install in order for them to work, like Buildroot already does. With Buildroot I can just tar/gz the toolchai

by m0zg 7y ago

I wish they'd generate toolchains I didn't have to install in order for them to work, like Buildroot already does. With Buildroot I can just tar/gz the toolchain and libs and integrate them into a build system. This lets me support cross-build in a relatively pain-free way. Buildroot toolchains do not care where they are located on the filesystem, so e.g. Bazel can download and unpack them without any issues and they work fine. In contrast, Yocto generates toolchains that have to be _installed_ and in which the installer has to _rewrite the locations of dynamic libs_ during installation. This makes Yocto toolchains effectively hostile to build automation.

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 ago
  Yes, 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 ago
    You'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 .]?

by m0zg 7y ago

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 ago
Yes, 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 ago
  You'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 .]?