Bug 7142

Summary:	cmake.bbclass fails when rebuilding after MACHINE changes
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Ross Burton <ross.burton>
Component:	devtools / tool chain	Assignee:	Ross Burton <ross.burton>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Medium	CC:	meta.mr.watcher, meta.watcher, richard.purdie
Version:	1.8
Target Milestone:	2.3 M2
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Ross Burton 2015-01-14 14:50:35 UTC

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.

Comment 1 Richard Purdie 2015-01-15 15:47:01 UTC

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.

Comment 2 Alexander Kanavin 2016-10-17 13:57:37 UTC

So if this is not a cmake specific issue, and needs to be sorted at the bitbake level, should I reassign to RP?

Comment 3 Richard Purdie 2016-12-22 16:14:52 UTC

Recipe specific sysroots are probably going to be the best way to fix this.

Comment 4 Ross Burton 2016-12-22 21:52:46 UTC

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.

Comment 5 Ross Burton 2016-12-22 22:27:59 UTC

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.

Comment 6 Ross Burton 2017-01-26 16:21:40 UTC

I *think* recipe-specific sysroots makes this moot.