If I do this: MACHINE=foo bitbake midori wipe-sysroot MACHINE=bar bitbake midori The compile for bar fails because it is using the foo sysroot (which doesn't exist). This is because the generated toolchain.cmake has absolute paths to the sysroot in, and doesn't get re-generated when MACHINE changes.
I believe the issue here is part of a larger issue for example: MACHINE=A bitbake perl -c configure MACHINE=B bitbake perl -c compile can also have interestig failures since the configure hardcodes paths to the MACHINE A sysroot, then we move to MACHINE B, some paths change and some paths do not. The best idea I can come up with to fix this is to make the WORKDIR consistent per machine. To do this we'd change MULTIMACH_TARGET_SYS and MULTIMACH_HOST_SYS to include MACHINE_ARCH instead of PACKAGE_ARCH.
So if this is not a cmake specific issue, and needs to be sorted at the bitbake level, should I reassign to RP?
Recipe specific sysroots are probably going to be the best way to fix this.
So the greater context that I didn't write down was that MACHINE foo and MACHINE bar were both identical tunes, so the work directory could be reused. Why this didn't mean that the toolchain generation task didn't rerun is beyond me. Recipe specific sysroots may well solve this anyway.
So the only way I can replicate this is by copying qemuarm to qemuarm-copy and then $ MACHINE=qemuarm bitbake libical $ wipe-sysroot $ MACHINE=qemuarm-copy bitbake libical -C compile You need to taint it otherwise it won't try and rebuild as the tunes match. If the tunes didn't match it wouldn't rebuilding... To be honest I'm really tempted to call this user error.
I *think* recipe-specific sysroots makes this moot.