Bug 4923

Summary: Cross-compilation issue with libexec when building for 32 bit host on arch 64.
Product: [Build System, Metadata & Runtime] Other YP Layers Reporter: Laszlo Papp <lpapp>
Component: layersAssignee: Christopher Larson <kergoth>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: kergoth, meta.mr.watcher, meta.watcher, poky.bs.watcher, poky.watcher, ross.burton, sgw
Version: unspecified   
Target Milestone: 1.5   
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
local.conf
none
bblayers.conf
none
installed-packages none

Description Laszlo Papp 2013-07-26 07:57:11 UTC 
Created attachment 1368 [details]
local.conf

Here you can find the toolchain I am using for this test:

https://developer.ridgerun.com/wiki/index.php/Code_Sourcery_ARM_toolchain_2009q1-203

Using poky and meta-sourcery master HEAD.

Same issue with 9.0.1 and master HEAD as with 9.0.0.

Any workaround? Otherwise, it is a blocker now.


bitbake core-image-minimal

WARNING: Host distribution "arch-rolling" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Parsing recipes: 100% |######################################################################################################################################################################################################| ETA:  00:00:00
Parsing of 848 .bb files complete (0 cached, 848 parsed). 1175 targets, 48 skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION        = "1.19.1"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "arch-rolling"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "qemuarm"
DISTRO            = "poky"
DISTRO_VERSION    = "1.4+snapshot-20130726"
TUNE_FEATURES     = "armv5 thumb dsp"
TARGET_FPU        = "soft"
CSL_VER_MAIN      = "2009q1-203"
EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"
meta-sourcery     = "master:832ce1937780bbb508050f02ac8a8bf309045fef"
meta              
meta-yocto        
meta-yocto-bsp    = "master:67864ca79da08df752487a3a4e1a975546da123d"

NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 4.3% of nativesdk-gcc-runtime not available (for item virtual/nativesdk-x86_64-pokysdk-linux-compilerlibs)
NOTE: versions of nativesdk-gcc-runtime available: 4.7.2 4.8.1
NOTE: preferred version 4.3% of gcc-crosssdk not available (for item virtual/x86_64-pokysdk-linux-gcc-crosssdk)
NOTE: versions of gcc-crosssdk available: 4.7.2 4.8.1
NOTE: preferred version 4.3% of nativesdk-libgcc not available (for item nativesdk-libgcc)
NOTE: versions of nativesdk-libgcc available: 4.7.2 4.8.1
NOTE: preferred version 4.3% of gcc-crosssdk not available (for item virtual/x86_64-pokysdk-linux-g++-crosssdk)
NOTE: versions of gcc-crosssdk available: 4.7.2 4.8.1
NOTE: preferred version 4.3% of gcc-crosssdk-initial not available (for item virtual/x86_64-pokysdk-linux-gcc-initial-crosssdk)
NOTE: versions of gcc-crosssdk-initial available: 4.7.2 4.8.1
NOTE: preferred version 4.3% of nativesdk-libgcc not available (for item nativesdk-libgcc)
NOTE: versions of nativesdk-libgcc available: 4.7.2 4.8.1
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_install (log file is located at /home/lpapp/Projects/poky/build/tmp/work/armv5te-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.8130)
ERROR: Logfile of failure stored in: /home/lpapp/Projects/poky/build/tmp/work/armv5te-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.8130
Log data follows:
| DEBUG: Executing shell function do_install
| cp: cannot stat '/usr/local/arm-2009q1/bin/../arm-none-linux-gnueabi/libc/usr/libexec': No such file or directory
| ERROR: Function failed: do_install (log file is located at /home/lpapp/Projects/poky/build/tmp/work/armv5te-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.8130)
ERROR: Task 31 (/home/lpapp/Projects/poky/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 91 tasks of which 0 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
  /home/lpapp/Projects/poky/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, do_install
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
Comment 1 Laszlo Papp 2013-07-26 07:57:27 UTC 
Created attachment 1369 [details]
bblayers.conf
Comment 2 Laszlo Papp 2013-07-26 08:04:10 UTC 
Created attachment 1370 [details]
installed-packages
Comment 3 Laszlo Papp 2013-07-26 16:09:38 UTC 
The main problem seems to be the fact that the libexec folder desired contains only an empty folder. Unfortunately when we use git for having a back up for our toolchain, empty folders get lost, of course.

Question is, why would meta-sourcery like to introspect an empty folder and demand it? Can this check be removed, please?
Comment 4 Christopher Larson 2013-07-26 17:10:22 UTC 
It copies paths it knows exists in the release. It's not empty in most versions of the toolchain, and the path does exist in the release toolchain you're using, so it's completely reasonable to copy a path we know exists. I'll add a check to work around libexec not existing for your case.
Comment 5 Laszlo Papp 2013-07-26 17:13:06 UTC 
For the love of God, please do not copy empty folders. They do not make any sense. If you do, do not release a toolchain with empty folders pretty please. Git and several other storages will drop the content of empty directories altogether.
Comment 6 Laszlo Papp 2013-07-26 17:50:36 UTC 
By the way, the oe-core sourcery support works just fine with denzil, so this libexec enforcement seems to have happened after that.

I believe it should work, at least for empty folders, like oe-core sourcery support. That would probably unblock me.

I cannot do much about git not tracking files, but content.
Comment 7 Christopher Larson 2013-07-26 18:03:07 UTC 
This should now be resolved, please confirm, thanks.
Comment 8 Laszlo Papp 2013-07-26 18:17:09 UTC 
OK, thanks.

Hopefully, I can do that on Monday.
Comment 9 Saul Wold 2013-07-26 18:24:09 UTC 
typically the assignee changes the status of the bugs, not the reporter.
Comment 10 Laszlo Papp 2013-07-26 18:26:14 UTC 
Sure, but I think Chris forgot to change, so in this special case, he just got some help. I think this kind of help is to be appreciated rather than discouraged.
Comment 11 Ross Burton 2013-09-25 10:35:54 UTC 
Laszlo, ping on Chris's request to verify the fix.
Comment 12 Laszlo Papp 2013-09-25 10:42:10 UTC 
To be honest, I do not have time in the foreseeable future to verify this, but if I recall correctly, I checked this back then.

I think it is ok to close this, and I will try to reopen if the issue is still hit.