Wind River Support Network

HomeDefectsLIN1019-3261
Fixed

LIN1019-3261 : do_populate_sdk hang in build with feature feature/kernel-dev

Created: Nov 5, 2019    Updated: Dec 15, 2019
Resolved Date: Dec 11, 2019
Found In Version: 10.19.45.1
Fix Version: 10.19.45.2
Severity: Standard
Applicable for: Wind River Linux LTS 19
Component/s: Kernel

Description

Log tail of the task

NOTE: Executing create_sdk_files ...
DEBUG: Executing shell function create_sdk_files
DEBUG: Shell function create_sdk_files finished
NOTE: Executing check_sdk_sysroots ...
DEBUG: Executing python function check_sdk_sysroots
DEBUG: Python function check_sdk_sysroots finished
NOTE: Executing archive_sdk ...
DEBUG: Executing shell function archive_sdk
DEBUG: Shell function archive_sdk finished
NOTE: Executing create_shar ...
DEBUG: Executing shell function create_shar
DEBUG: Shell function create_shar finished
DEBUG: Python function do_populate_sdk finished
DEBUG: Executing python function kernel_sdkpostprocess
NOTE: kernel SDK: start
NOTE: kernel SDK: kernel source found, creating scripts
HANG HERE...

Below is what are hung.

 560974 ?        S      0:00 /bin/sh -c cd /buildarea1/xhou/builds/11051550-build_kernel_module_in_sdk/intel-x86-64-standard-glibc-std/build/tmp-glibc/work/intel_x86_64-wrs-linux/wrlinux-image-glibc-std/1.0-r5/sdk/image/opt/windriver/wrlinux/19.45/sysroots/corei7-64-wrs-linux/usr/src/kernel; pwd; make CROSS_COMPILE= scripts
 561031 ?        R     27:20 make -C /buildarea1/xhou/builds/11051550-build_kernel_module_in_sdk/intel-x86-64-standard-glibc-std/build/tmp-glibc/work/intel_x86_64-wrs-linux/wrlinux-image-glibc-std/1.0-r5/sdk/image/opt/windriver/wrlinux/19.45/sysroots/corei7-64-wrs-linux/lib/modules/5.2.21-yocto-standard/build -f /buildarea1/xhou/builds/11051550-build_kernel_module_in_sdk/intel-x86-64-standard-glibc-std/build/tmp-glibc/work/intel_x86_64-wrs-linux/wrlinux-image-glibc-std/1.0-r5/sdk/image/opt/windriver/wrlinux/19.45/sysroots/corei7-64-wrs-linux/lib/modules/5.2.21-yocto-standard/build//Makefile scripts

Workaround

From what we have got now, we highly suspect it's because the python funtion os.path.realpath that we build from source is so new that might contain some bug. So we recommend not sourcing environment-setup-x86_64-wrlinuxsdk-linux under project directory where setup.sh is run. That is, trying to the older python on the build machine. 

Steps to Reproduce

$ git clone -b WRLINUX_10_19_LTS git://lxgit.wrs.com/wrlinux-x wrlinux-10
or
$ git clone -b WRLINUX_10_19_LTS git://pek-git.wrs.com/wrlinux-x wrlinux-10

$ ./wrlinux-10/setup.sh --machines=intel-x86-64 --dl-layers --accept-eula=yes
$ bitbake-layers  add-layer ../wrlinux/wrlinux-kernel-dev
$ echo 'WRTEMPLATE += "feature/kernel-dev"' >> conf/local.conf
$ echo 'ENABLE_KERNEL_DEV = "1"'>> conf/bblayers.conf
$ bitbake -c populate_sdk wrlinux-image-glibc-std 
Live chat
Online