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>
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.
Since ac83d22eb5
The armvX arch definition is not present in TUNE_FEATURES but is now in
MACHINEOVERRIDES. Improve parsing so that MACHINEOVERRIDES is also checked.
Fixes#240
Tested on raspberrypi3 with balenaOS which uses rust.
Signed-off-by: Zubair Lutfullah Kakakhel <zubair@balena.io>
Since 1.31.0 cargo requires curl to support http2. Enabling http2 in
curl results in a dependency loop. This commit disables the use of
multiplexing and http2.
ARM_INSTRUCTION_SET, and therefore ARM_THUMB_OPT also, expect to only be
used in conjunction with the thumb TUNE_FEATURES. So thumb-mode should only
be added if thumb is in TUNE_FEATURES and ARM_THUMB_OPT is thumb.
The commit https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/conf/machine/include/arm/arch-armv7a.inc?id=3e7d26e31a724009e69788460737e07163a14051
caused armv7a.inc to set ARM_INSTRUCTION_SET to thumb and the commit
message explicitly states that the change should have no effect unless
TUNE_FEATURES also includes thumb. This change to rust will allow that
assumption to continue to be true.
musl builds need libunwind.a to be in sysroot for libstd-rs to build
unwinding support into it. This also means we need to compile libunwind
with --enable-static in oe-core
Signed-off-by: Khem Raj <raj.khem@gmail.com>
We were already trying to disable assertions, but it wasn't working.
rust-llvm now configures assertions based on the CMAKE_BUILD_TYPE.
Setting that to "Release" causes assertions to be disabled, which is
what we want.
