Bug 9469

Summary: Extensible SDK: Installation failure
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Phlip Balister <philip>
Component: devtools / tool chainAssignee: Paul Eggleton <bluelightning>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: High CC: bluelightning, meta.mr.watcher, meta.watcher, stephano
Version: unspecified   
Target Milestone: 2.1 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
/home/balister/sdks-ext/Alchemy_sdk/preparing_build_system.log none

Description Phlip Balister 2016-04-14 23:46:54 UTC
Created attachment 3127 [details]
/home/balister/sdks-ext/Alchemy_sdk/preparing_build_system.log

I build the extensible sdk for the gnuradio-dev-image. Of specific interest oe-core and bitbake are at the same level, not bitbake in the oe-core directory.

I try to install the sdk and see:

[balister@thuvia sdks-ext]$ sh ~/src/oe-core/build/tmp-glibc/deploy/sdk/oecore-x86_64-armv7ahf-neon-toolchain-ext-nodistro.0.sh 
OpenEmbedded Extensible SDK installer version nodistro.0
========================================================
Enter target directory for SDK (default: ~/Alchemy_sdk): ./Alchemy_sdk
You are about to install the SDK to "/home/balister/sdks-ext/Alchemy_sdk". Proceed[Y/n]? 
Extracting SDK......................................................................................................................................................done
Setting it up...
Extracting buildtools...
Preparing build system...
ERROR: SDK preparation failed: see /home/balister/sdks-ext/Alchemy_sdk/preparing_build_system.log


The log file suggest failure detecting some perl modules, but double checking with dnf install suggest they are installed. This is on a Fedora 23 machine. The modules are not in /usr/lib/perl...
Comment 1 Stephano Cetola 2016-04-17 19:15:38 UTC
Perl has snuck its way back into buildtools:

sysroots/x86_64-oesdk-linux/usr/bin/perl

I looked for recent changes that might have caused this to happen. I found this commit, and when I rolled it back, the perl executable was no longer included in buildtools.

https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg79337.html

I'm not sure why nativesdk-buildtools-perl-dummy isn't working as it used to, or for that matter, why this doesn't seem to happen in Yocto. I'm still digging into these things.
Comment 2 Paul Eggleton 2016-04-17 23:06:38 UTC
Philip sent me his minimal SDK installer and I've noticed that python has apparently sneaked into the host part of the SDK - that shouldn't be there either since the buildtools already provides it and without relocation (which is disabled by the eSDK installer) it is broken. Philip, do you have TOOLCHAIN_HOST_TASK(_append) set somewhere?
Comment 3 Paul Eggleton 2016-04-17 23:46:24 UTC
The perl-in-buildtools problem appears to be triggered by using ipk, at least; I've reproduced that here with poky by setting PACKAGE_CLASSES = "package_ipk". I guess opkg isn't giving nativesdk-buildtools-perl-dummy package precedence for some reason.
Comment 4 Paul Eggleton 2016-04-18 21:24:52 UTC
Fix merged to master and krogoth:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c219c6d5826b6f1002f5486eceeb1cc8990d7c28
Comment 5 Paul Eggleton 2016-04-18 22:39:53 UTC
FYI I've created bug 9479 to cover python being added via TOOLCHAIN_HOST_TASK and breaking the eSDK.