Hello Richard,
On 19-04-2022 13:10, Richard Purdie wrote:
On Sun, 2022-04-10 at 23:00 -0700, Sundeep KOKKONDA wrote:
The build shows below error while building for arm machines.
Exception: TypeError: int() argument must be a string, a bytes-like object or a
number, not 'NoneType'
Detailed error info :
Steps to reproduce:
1. Set MACHINE ?= "qemuarm" in local.conf & add 'TOOLCHAIN_HOST_TASK:append = "
packagegroup-rust-cross-canadian-${MACHINE}"'
2. bitbake core-image-minimal -cpopulate_sdk
Complete Error:
ERROR: rust-cross-canadian-arm-1.59.0-r0 do_rust_gen_targets: Error executing a
python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_rust_gen_targets(d)
0003:
File:
'/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-cross-canadian-common.inc',
lineno: 31, function: do_rust_gen_targets
0027:
0028:LLVM_TARGET[x86_64] = "${RUST_HOST_SYS}"
0029:python do_rust_gen_targets () {
0030: wd = d.getVar('WORKDIR') + '/targets/'
*** 0031: rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or
"", d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
0032: rust_gen_target(d, 'HOST', wd, "", "generic",
d.getVar('HOST_ARCH'))
0033: rust_gen_target(d, 'BUILD', wd, "", "generic",
d.getVar('BUILD_ARCH'))
0034:}
0035:
File:
'/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-common.inc',
lineno: 330, function: rust_gen_target
0326: # build tspec
0327: tspec = {}
0328: tspec['llvm-target'] = d.getVarFlag('LLVM_TARGET', arch_abi)
0329: tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
*** 0330: tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH',
arch_abi))
0331: tspec['target-pointer-width'] =
d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
0332: tspec['target-c-int-width'] = d.getVarFlag('TARGET_C_INT_WIDTH',
arch_abi)
0333: tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
0334: tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like object or a
number, not 'NoneType'
Below are the local variables from rust_gen_target function for arm and aarch64
targets. Refer below, the tspec varibles for 'arm' generated with NoneType.
(a) Locals at rust_gen_target for arm::
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class 'NoneType'>
tspec['data-layout'] = None, Type of tspec['data-layout'] = <class 'NoneType'>
DEBUG: Python function do_rust_gen_targets finished
(b) Locals at rust_gen_target for aarch64::
tspec['data-layout'] = aarch64-unknown-linux-gnu, Type of tspec['data-layout'] =
<class 'str'>
tspec['max-atomic-width'] = 128, Type of tspec['max-atomic-width'] = <class
'int'>
Reason for changing arm-eabi to arm: The previous change introduced this bug,
so reverting the change 'arm-eabi' to 'arm' fixed the issue.
Signed-off-by: Sundeep KOKKONDA<[email protected]>
---
meta/recipes-devtools/rust/rust-common.inc | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-devtools/rust/rust-common.inc
b/meta/recipes-devtools/rust/rust-common.inc
index 310aecef22..230d78237f 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,13 +119,13 @@ def llvm_features(d):
## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"
## armv7-unknown-linux-gnueabihf
DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
We've dropped this patch from testing. Why? It has been sent in a few different
forms and testing shows there are deeper problems which need to be solved
including that the automated testing results are erratic.
The big issue is that changes here don't seem to invalidate the sstate cache.
This means that tests "pass" on the autobuilder initially but then when some
later change does cause a rebuild of this code, it then fails.
As such I have no confidence this change is correct, tested or won't cause
future failures.
The issue is that changes to the data above are not being reflected in task
sstate signatures. We need to debug and fix the sstate problem first, then we
can come back to this patch.
I analyzed the issue, the signature data of a Task is getting changed
only when the Task is changed i.e., changes made '/within/' the Task
definition (in this case '/rust_gen_target/' task). See the below sigdiff.
/[skokkond@yow-fedora-builder1 buildA]$ bitbake-diffsigs
tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.db412211fa29be71edbefb70b984c591b6818c3d238e29abf6c7a59f729fe13d
../buildB/tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.e56abb44c5d1544da8761ae0335e8c42faab6f61413ee7482c8a3797ae45d6b9//
//NOTE: Starting bitbake server...//
//basehash changed from
6a46ad5360b899c64cb2b3f9a9d41de2977d6b86e86d7fe2f25cb8d07bdeae15 to
7f93e436bb9f87ddcab0359945a3116faf6e9313ff4ae042fcb03d37925b1e92//
//Variable rust_gen_target value changed://
//@@ -1,15 +1,18 @@//
// def rust_gen_target(d, thing, wd, features, cpu, arch, abi="")://
//+ print("Inside rust_gen_target....")//
// import json//
// sys = sys_for(d, thing)//
// prefix = prefix_for(d, thing)//
//
// rust_arch = oe.rust.arch_to_rust_arch(arch)//
//+ print("rust_arch = ", rust_arch)//
//
// if abi://
// arch_abi = "{}-{}".format(rust_arch, abi)//
// else://
// arch_abi = rust_arch//
//
//+ print("arch_abi = ", arch_abi)//
// features = features or d.getVarFlag('FEATURES', arch_abi) or ""//
// features = features.strip()/
Along with the above changes in '/rust_gen_target/' task below changes
are also present in the '//meta/recipes-devtools/rust/rust-common.inc/'
file. The below changes are definition of variables and these are /not
part/ of any Task definition. But the '/rust_gen_target'/ Task will use
this data when it is building.
/ ## arm-unknown-linux-gnueabihf//
//-DATA_LAYOUT[arm-eabi] =
"e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"//
//-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"//
//-TARGET_ENDIAN[arm-eabi] = "little"//
//-TARGET_POINTER_WIDTH[arm-eabi] = "32"//
//-TARGET_C_INT_WIDTH[arm-eabi] = "32"//
//-MAX_ATOMIC_WIDTH[arm-eabi] = "64"//
//-FEATURES[arm-eabi] = "+v6,+vfp2"//
//+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"//
//+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"//
//+TARGET_ENDIAN[arm] = "little"//
//+TARGET_POINTER_WIDTH[arm] = "32"//
//+TARGET_C_INT_WIDTH[arm] = "32"//
//+MAX_ATOMIC_WIDTH[arm] = "64"//
//+FEATURES[arm] = "+v6,+vfp2"/
The Yocto build system is not changing the signature of the Task when
only these variable changes are present (w/o the changes in
'/rust_gen_target/' task definition).
In the current patch, there are no changes in the '/rust_gen_target/'
task definition and so the signature is not updated hence the
'/rust_gen_target/' task is not rebuilded.
I am not sure this behavior is a bug in Yocto or it is the expected
behavior.
Also, in the build config the MACHINE set as "beaglebone-yocto", and I
expected a change of signature in
'/tmp/stamps/*beaglebone_yocto-poky-linux-gnueabi*/*/' but the sigdata
file changed in '/tmp/stamps/*x86_64-linux/rust-native*/'. I am looking
into it, but any clue here will be helpful.
Let me know if anything is not clear.
Thanks,
Sundeep K.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165296):
https://lists.openembedded.org/g/openembedded-core/message/165296
Mute This Topic: https://lists.openembedded.org/mt/90389343/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
