As a user i want to override `RUSTLIB` path on a bbclass, lets
call it `XYZ.bbclass`.
If a certain recipe inherits `cargo.bbclass` and `XYZ.bbclass` the
value of `RUSTLIB` is dependent on the order of the inherit.
If `cargo.bbclass` is inherit before `XYZ.bbclass` this will reflect
the desired value of `RUSTLIB`, on the oposite, if the `XYZ.bbclass`
is inherit before `cargo.bbclass` then the `RUSTLIB` defined on
`rust-common.bbclass` will prevail.
Changed definition of `RUSTLIB` to soft assignment to make it overridable.
(From OE-Core rev: d8ccc3ad338a8020c998566249af2019baaa6e44)
Signed-off-by: Pedro Silva Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit 6eeb832f73ffb48f5f05dc47191f60e4599e640f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Building with MACHINE=qemuarm and MACHINE=qemux86-64 causes rust-native
to rebuild. The reason is all the ingredients into the RUST_*_SYS
variables are being tracked but that doesn't really make sense in this
case:
$ bitbake-diffsigs tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.63* tmp/stamps/x86_64-linux/rust-native/1.60.0-r0.do_rust_gen_targets.sigdata.34*
NOTE: Starting bitbake server...
basehash changed from 860b8f11b10182dc5b2737f62cdb697477f714adb63eeb4d4b932d67cac8eec2 to 9379e8b9df9696e8056fec7d1534661f34dda073f6d816e241b09a2dff76ae2d
Variable rust_base_triple value changed:
@@ -36,4 +36,4 @@
# In some cases uname and the toolchain differ on their idea of the arch name
-TUNE_FEATURES{callconvention-hard} = Set
+TUNE_FEATURES{callconvention-hard} = Unset
Switch to using the final variable value for sstate signature purposes
which avoids this issue.
(From OE-Core rev: 424b81ae680057a8c285157ea081f167381b6c62)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 38b61aeaf877f6a34c3c0060c175119975ebd782)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For nativesdk/crosssdk, always glibc is used. Fixes build of
rust-crosssdk if TCLIBC is set to musl.
(From OE-Core rev: 67b4e0fdb13c81ab7e79109b6366fd7705b253ba)
Signed-off-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RUST_BUILD_ARCH contains the arch_to_rust_arch()-translated value of
BUILD_ARCH. This is necessary to acquire the correct snapshot artifacts
under Linux where `uname -m` reports "ppc64le" rather than
"powerpc64le".
Change-Id: I6aec23aced8e1c6f0bfc46fe52531b0c16bcf687
(From OE-Core rev: c13afbade8d480807b9de70c56dcd650496f06b2)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On modern Power systems `uname -m` yields 'ppc64le' while the toolchain
knows the architecture as 'powerpc64le'. Provide a mapping from one to
the other to integrate with the existing architecture configuration
flags.
arch_to_rust_arch() only exists to map the OE *_ARCH variables before
any further processing, unlike arch_to_rust_target_arch() which is
specific to the internal triple handling of rust.
On Linux ppc64le systems the changes give the following config:
```
$ cat ./tmp/work/ppc64le-linux/rust-native/1.58.0-r0/targets/ppc64le-linux.json
{
"llvm-target": "powerpc64le-unknown-linux-gnu",
"data-layout": "e-m:e-i64:64-n32:64-v256:256:256-v512:512:512",
"max-atomic-width": 64,
"target-pointer-width": "64",
"target-c-int-width": "64",
"target-endian": "little",
"arch": "powerpc64",
"os": "linux",
"env": "gnu",
"vendor": "unknown",
"target-family": "unix",
"linker": "gcc",
"cpu": "generic",
"dynamic-linking": true,
"executables": true,
"linker-is-gnu": true,
"linker-flavor": "gcc",
"has-rpath": true,
"has-elf-tls": true,
"position-independent-executables": true,
"panic-strategy": "unwind"
}
```
Change-Id: Ief0c01189185d7d4da31d307270bec4e1de674ca
(From OE-Core rev: 9ab61e3cfef0157393cb870d606c2f362e190889)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
librsvg on centos 7 and friends exhibits the same libtinfo leakage
problem, this time coming from the compiler and not the linker.
Simply covering the compiler by the existing C wrapper-of-wrapper
does not work, as rust-native builds put Important Stuff into
LD_LIBRARY_PATH and unsetting it breaks things badly.
Rather than try to figure out which combination of wrappers and
LD_LIBRARY_PATH settings works for which situation, or provide
some kind of sh-native, let's simply use python3-native for the
wrappers, which should insulate builds from the the host shell.
rust-native already depends on python3-native, so this does not
lengthen the builds.
This also reverts:
rust-common: Hack around LD_LIBRARY_PATH issues on centos7
(commit 63b1fd2226).
I'd also like to say boo to Red Hat (or GNU?) for breaking ABI
compatibility for stat() in glibc 2.33, we ended up sorting
this mess because of it.
(From OE-Core rev: 997d54363a3cb3a0e949b3626855f2fa41afeb2b)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It fails to run task rust_create_wrappers of recipe which inherit
rust-common.bbclass such as rust-hello-world if no host ccache exists:
| DEBUG: Executing shell function do_rust_create_wrappers
| /path/to/project/tmp-glibc/work/core2-64-wrs-linux/rust-hello-world/git-r0/temp/run.do_rust_create_wrappers.3422:
line 179: ccache: command not found
Run task rust_create_wrappers before do_prepare_recipe_sysroot to make
sure required tools such as ccache exist.
(From OE-Core rev: 46575e0d5b9e722558b64e22ed928e6d7b2c654a)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building cargo-native on centos7 with buildtools tarball installed,
we see failures:
/bin/sh: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /home/pokybuild/yocto-worker/reproducible-centos/build/build-st/tmp/work/x86_64-linux/cargo-native/1.54.0-r0/recipe-sysroot-native/usr/lib/libtinfo.so.5)
We also see this for libstd-rs once cargo-native is fixed.
The reason for this is that the wrapper script
cargo-native/1.54.0-r0/wrapper/target-rust-ccld has /bin/sh as it's
interpreter and cargo calls this with LD_LIBRARY_PATH set to include the
recipe-sysroot-native. The host /bin/sh links to libtinfo from the host
but it finds the version in the sysroot which needs a newer libc. This
results in the above error since the loader is an older libc and the two
are incompatible.
Our ccld wrapper calls gcc/ld which don't need the LD_LIBRARY_PATH
variable set. We can't patch this out the source since we're using
a prebuilt binary to generate a new cargo binary so this is impossible
to bootstrap.
Instead, put a binary wrapper into place which removes LD_LIBRARY_PATH
from the environment before calling the original wrapper (left in shell
as it is simpler to maintain).
(From OE-Core rev: 8feeeb7f76c6725e5226458c8f22999b67c52694)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running 'rustc --print <foo>' in -c devshell environment
the target specifications are not known, unless the
RUST_TARGET_PATH (absolute path to rustlib/) is defined.
(From OE-Core rev: 6d0603ffe18c1a5999db854abb668b05aff47f67)
Signed-off-by: Tim Orling <timothy.t.orling@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The -cc wrapper can be used for linking and can fail if key flags are missing:
| error: linking with `[path]/tmp/work/x86_64-linux/rust-native/1.54.0-r0/wrapper/target-rust-cc`
Add the flags to fix builds even if that is counter-intuitive (cc would
normally be used for compiling and ccld for linking).
(From OE-Core rev: 62242e83c49b81a9ea65c9a1f5957a7c309d910a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The oeqa selftest test:
sstatetests.SStateTests.test_sstate_sametune_samesigs
which checks if the sstate checksums of two identical machines
(using the same tune) are the same, apart from changes within
the machine specific stamps directory, fails on the assertion:
self.assertCountEqual(files1, files2)
due to the signature of various 32 bit package builds such as:
x86_64-linux/lib32-rust-cross-i686
x86_64-linux/rust-cross-i686
x86-pokymllib32-linux/lib32-libstd-rs
x86-pokymllib32-linux/lib32-rust
differing. Jumping down the rabbit hole past all the bitbake-diffsig
outputs that differ due to dependent hashes, you come to a diff of:
-Variable MACHINEOVERRIDES value is ${@bb.utils.contains('TUNE_FEATURES', 'mx32', 'x86-x32:', '', d)}${@bb.utils.contains('TUNE_FEATURES', 'm32', 'x86:', '', d)}qemuall:${MACHINE}
+Variable MACHINEOVERRIDES value is ${@bb.utils.contains('TUNE_FEATURES', 'mx32', 'x86-x32:', '', d)}${@bb.utils.contains('TUNE_FEATURES', 'm32', 'x86:', '', d)}qemuall:${MACHINE}:qemux86
in
stamps/x86_64-linux/rust-cross-i686/1.54.0-r0.do_rust_gen_target.<sig>
This is because there are two rust functions referencing OVERRIDES
related variables (target_is_armv7 and llvm_features_from_tune). These
indirectly influnce the build and should be excluded from the signatures
directly as is done in other toolchain recipes, e.g.:
39bfa0dd32 recipes/*-cross recipes: ignore TARGET_ARCH sstate hash
(From OE-Core rev: 72d67410e92207a98a801ddf0cb9f1297a752975)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
