This reverts commit 5dda6c427a.
This breaks rust-llvm builds with:
ERROR: QA Issue: rust-llvm-native: LIC_FILES_CHKSUM points to an invalid file: TOPDIR/BUILD/work/x86_64-linux/rust-llvm-native/1.47.0-r0/rustc-1.47.0-src/src/llvm-project/llvm/COPYRIGHT [license-checksum]
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
If the libstd-rs recipe is not correctly embedding LVM bitcode in its
output, then it can produce a toolchain that appears to work until you
try building a project that requests LTO:
error: failed to get bitcode from object file for LTO (Bitcode section not found in object file)
Enable LTO for rust-hello-world to give us an easy watch to catch such
problems.
Fixes dependency loop
These are usually caused by circular dependencies and any circular dependency chains found will be printed below. Increase the debug level to see a list of unbuildable tasks.
Identifying dependency loops (this may take a short while)...
ERROR:
Dependency loop #1 found:
Task virtual:native:/mnt/b/yoe/master/sources/meta-rust/recipes-devtools/cargo/cargo_1.47.0.bb:do_compile (dependent Tasks ['cargo_1.47.0.bb:do_configure'])
Task virtual:native:/mnt/b/yoe/master/sources/meta-rust/recipes-devtools/cargo/cargo_1.47.0.bb:do_install (dependent Tasks ['cargo_1.47.0.bb:do_compile'])
Task virtual:native:/mnt/b/yoe/master/sources/meta-rust/recipes-devtools/cargo/cargo_1.47.0.bb:do_populate_sysroot (dependent Tasks ['cargo_1.47.0.bb:do_install'])
Task virtual:native:/mnt/b/yoe/master/sources/meta-rust/recipes-devtools/cargo/cargo_1.47.0.bb:do_prepare_recipe_sysroot (dependent Tasks ['cargo_1.47.0.bb:do_populate_sysroot', 'openssl_1.1.1i.bb:do_populate_sysroot', 'curl_7.74.0.bb:do_populate_sysroot', 'rust_1.47.0.bb:do_populate_sysroot', 'zlib_1.2.11.bb:do_populate_sysroot', 'ca-certificates_20210119.bb:do_populate_sysroot', 'libssh2_1.9.0.bb:do_populate_sysroot', 'cargo_1.47.0.bb:do_fetch'])
Task virtual:native:/mnt/b/yoe/master/sources/meta-rust/recipes-devtools/cargo/cargo_1.47.0.bb:do_configure (dependent Tasks ['cargo_1.47.0.bb:do_prepare_recipe_sysroot', 'cargo_1.47.0.bb:do_patch', 'cargo_1.47.0.bb:do_rust_create_wrappers', 'cargo_1.47.0.bb:do_cargo_setup_snapshot'])
ERROR: Command execution failed: 1
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Because rust-llvm-ncsa.inc requires rust-llvm.inc we do not want that
the latter overrides the license checksum set in the former.
Signed-off-by: Florin Sarbu <florin@balena.io>
Place generated artifacts in the directory suggested by bitbake (${B})
instead of directly in the source directory. This has multiple
advantages such as the ability to share source directory between
multiple machine types without risking cross contamination.
arm-unknown-linux-gnueabihf was incorrectly used as llvm-target instead
of armv7-unknown-linux-gnueabihf when building for some Cortex A SoCs.
This may cause segfaults in non trivial rust applications on ARMv7
when e.g. +a7 is passed to LLVM. It seems to differ between different
versions of the compiler and LLVM versions.
* BB_NUMBER_THREADS is number of bitbake tasks running in
parallel, not parallelization inside individual tasks
* use oe.utils.parallel_make_argument to make sure it
works even when people add e.g. "-l 10" in PARALLEL_MAKE
* with the recent improvements for rust-native build time, I wanted
to rerun some build time tests from
https://github.com/shr-project/test-oe-build-time
here are the results on AMD Threadripper 3970x with 128GB ram:
BB is BB_NUMBER_THREADS
PM is PARALLEL_MAKE
TIME BB PM Description
20:50 * * zeus based build with 1.37 rust (BB/PM has no impact)
14:50 8 32,48,64 dunfell, 1.43 as in d2ff87ca55 (PM has no impact, because bootstrap uses BB)
9:50 8 32,48,64 dunfell, 1.43 with this patch applied, it doesn't get faster after some threashold of PM
13:32 8 64 dunfell, 1.43 with this patch applied and "rust.inc: cut build time in half" (afcb58e5b9) reverted
13:30 8 64 dunfell, 1.43 with "rust.inc: cut build time in half" (afcb58e5b9) as well as "rust.inc: run bootstrap.py in parallel" (40a6bd8a8d) reverted to see if 1.43 builds faster without any meta-rust improvements compared to 1.37
94:47 1 64 dunfell, 1.43 as in d2ff87ca55 (either something went wrong or explicit "-j 1" disables some parallelism done by default already
13:40 * * zeus based build with 1.39 rust (BB/PM has no impact)
10:50 8 64 zeus based build with 1.39 rust as proposed in jansa/new-zeus-branch
80:51 8 1 zeus based build with 1.39 rust as proposed in jansa/new-zeus-branch with "-j 1" PARALLEL_MAKE
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
d55cce6b8b6b510bf4905f19b949f7995af57a4d added a use of
BB_NUMBER_THREADS which is not whitelisted in Poky. This caused machines
with a different number of CPUs to have different sstate for
rust-native.
As a string this was actually being ignored. It mostly didn't matter
because max-atomic-width falls back to target-pointer-size, and they are
usually the same. However, at least on i586, 64-bit atomics are
supported with a 32-bit pointer size.
The whole point of rust-native is that it should be common for all
targets. If we reference TARGET variables during the build of
rust-native, then bitbake will build a different version for different
TARGETS.
