| Summary: | Failed to install sdk_ext for i686 | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Yi Zhao <yi.zhao> |
| Component: | devtools / tool chain | Assignee: | Richard Purdie <richard.purdie> |
| Status: | VERIFIED FIXED | QA Contact: | Yi Zhao <yi.zhao> |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | alexandru.c.georgescu, henry.bruce, jose.perez.carranza, ke.zou, meta.mr.watcher, meta.watcher, randy.e.witt, yi.zhao |
| Version: | 2.1 | ||
| Target Milestone: | 2.2 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
I did actually change this error back to a warning and sent the patch to the list. That creates the same behavior as before. However, previously it only "appeared" to be working and wasn't really behaving like we intend and extensible sdk to behave. I'll try to explain why. When created the esdk the locked-sigs.inc file ends up with signatures for all the native items and stores them in SIGGEN_LOCKEDSIGS_t-i686. However, when building on x86_64 those locked-signatures aren't used and instead it fetches and builds the entire native set of tools. Even when using the full esdk rather than the minimal, pseudo fails to load when building the rootfs because there is no 64-bit libpseudo available. Also this means we would probably need preserve BUILD_ARCH as part of the sdk. Honestly I don't have it all figured out yet, and the question is do we want to support running a 32-bit esdk on a 64-bit system? We can make it work if we make the sdk self-contained, but do we want to take the time to support it? You can always build the esdk for 64-bit as well as 32-bit. I see this problem on krogoth with default SDKMACHINE Preparing SDK for meta-world-pkgdata:do_allpackagedata... Parsing recipes...done. Parsing of 871 .bb files complete (0 cached, 871 parsed). 1301 targets, 47 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: Preparing RunQueue NOTE: Checking sstate mirror object availability (for 1788 objects) ERROR: The meta-world-pkgdata:do_allpackagedata sig is computed to be 03dc86096b45d9dcf3453919a28242bf, but the sig is locked to e6ab2f4f7e63ef0f45a804410c286e36 in SIGGEN_LOCKEDSIGS_t-i586 I can fix with http://patchwork.openembedded.org/patch/121313/ Why hasn't this been merged? This issue doesn't happen recently. The eSDK can install without problems on Fedora 24. We can close this bug. Closing as QA can no longer reproduce. This issue doesn't exist both in 2.2 and 2.1.2. Verified it. |
Git rev: krogoth/6c1c01392d91f512e2949ad1d57a75a8077478ba Environment: Debian 8.0 i686 and Fedora 23 i686 Steps: 1. Set MACHINE = "qemux86" and SDKMACHINE = "i686" 2. Run bitbake core-image-sato -c populate_sdk_ext 3. Install the sdk_ext Error message: ########################################## ### Shell environment set up for builds. ### You can now run 'bitbake <target>' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' Preparing SDK for core-image-sato... Parsing recipes...done. Parsing of 871 .bb files complete (0 cached, 871 parsed). 1301 targets, 47 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: Preparing RunQueue ERROR: The pseudo-native:do_compile sig is computed to be d79c6aade5e9d8ae453a9854fab406da, but the sig is locked to 64ce8231b897e92756081959084eaf90 in SIGGEN_LOCKEDSIGS_t-i686 The pseudo-native:do_install sig is computed to be c38f294136dd5a1ca94da75026d723ff, but the sig is locked to 30026da5835ed3320832294e4d0e16aa in SIGGEN_LOCKEDSIGS_t-i686 ################################### This is a regression bug, used to work in 2.1 RC1.