There was a bbnote that showed the path to the rustc and cargo binaries
being used but this was not necessarily correct since it didn't use the
exact variables used.
For similar reasons to the C and linker wrappers, using rustbuild
requires a C++ wrapper to ensure that the right flags that Yocto needs
are passed to the underlying compiler.
The crate_hash flag is no longer accepted on rust 1.14. Additionally,
due to the use of wrapper scripts by cargo, we were no longer able to
link correctly due to some link flags getting dropped. Fix that as well
The -C crate_hash option does not work if multiple versions of the same
crate are being linked into a binary. This can happen if different
dependencies depend on different versions of the same crate. The -C
crate_hash argument causes all versions of a given crate to have the
same crate hash which in turn causes the compiler to select the wrong
one internally and crash. This works around issue #126 for Cargo builds
but does not fix the underlying cause.
Reworked the source redirection to use directory source redirection like
I've done for Gentoo. This allows us to specify all crate dependencies
in the bitbake SRC_URI and have Yocto fetch them down using our crate
fetcher and then Cargo will build without reaching out to the network.
Don't supply the linker arguments via rustflags and then mangle with the
RUSTFLAGS environment variable. This is also a parial reversion of
4e1bda643e and 5afc0cc471. These changes are reverted since it assumed
people would build with cargo and not directly with rustc. ref #116.
We don't use the native Rust triples but instead use the Yocto triples
so we need to provide this override properly. This typo was introduced
in 5afc0cc471.
Firstly, HOST_CC_ARCH and TOOLCHAIN_OPTIONS are included in CC so them
being passed in are redundant now (due to the wrapper). The RUST_CFLAGS
variable doesn't need to be exported since its not actually used by
rustc/gcc-rs/cargo. Since its redundant and doesn't need to be exported,
remove it and simplify.
Firstly, BUILD_CC_ARCH is included in BUILD_CC (hence why we actually
need a BUILD_CC wrapper because it produces the space), so its
redundant (now with the wrapper using BUILD_CC). The RUST_BUILD_CFLAGS
variable doesn't need to be exported since its not actually used by
rustc/gcc-rs/cargo. Since its redundant and doesn't need to be
exported remove it and simplify.
Rust builds (custom build.rs and gcc-rs users) expect to have the
compiler and the linker available to them as a single command with no
white space trailing. Yocto unfortunately does not conform to that. The
build compiler and linker almost always have a trailing space due to
how the variables are composed and the target compiler and linker are
almost always more than a single command. Then if you throw ccache into
the mix you'll get another command. As a result to handle all these
cases properly there need to be wrappers created. This change creates
wrappers for both build and target and both the linker and compiler.
This likely fixes#76.
Provide documentation behind what the triples mean for Yocto and Rust
since they have different meanings of BUILD, TARGET, and HOST. Namely
Rust uses HOST when Yocto means BUILD. In our current supported cases
HOST and TARGET from Yocto mean the same thing.
The RUSTFLAGS env var overrides the rustflags specified in the cargo
config so we need to take anything passed in the environment variable
and put it in the config.
Supply the linker and the linker args via rustflags which should make it
not necessary to specify them via target JSONs. We explicitly cannot use
the RUSTFLAGS environment variable do to the way cargo parses arguments
and passes them to rustc.
The old cargo.bbclass had no users in meta-rust and had lots of
problems (not least of which was lots of duplicated lines with
cargo_util.bbclass). Delete the old cargo.bbclass and replace it
entirely wiht cargo_util
The local registry is a more future-proof way to prevent cargo from
accessing the network during the build. Unfortunately, this is only
used during the build of cargo-native for now. The snapshot used while
building cargo-native supports using a local registry ("source
replacement") however the version of cargo supported by rust 1.10 does
not.
Until we can build a new-enough version of cargo that supports
source-replacement, we'll have to patch cargo directly to prevent it
from accessing the network. Once we do have a new-enough cargo, we can
stop populating cargo_home/registry and only create cargo_registry.
Instead of building a full compiler, we can use rust-native to
cross-compile. All we need is a cross-compiled standard library, which
libstd-rs builds, and a compiler spec file. rust-cross is now just used
to generate the json spec file for cross-compiling, which is naturally
much faster.
The oe-core/poky change 'base.bbclass wipe ${S} before unpacking
source' (poky: a56fb90dc3805494eeaf04c60538425e8d52efc5, oe-core:
eccae514b71394ffaed8fc45dea7942152a334a1) wipes ${S} in do_unpack prior
to unpacking. This breaks our shared source as we set ${S} to the shared
location, and don't actually unpack anything (the result is we try to
build rustc without any source code, which fails predictably)
Avoid this by clearing do_unpack[cleandirs].
At the same time take pieces of gcc-shared-source.inc and note how & why
we differ from how gcc operates.
This is a bit of a hack, and only happens to work because we know the
exact method that do_unpack uses to clear ${S}, and using python()
happens to get called at the "right time".
RUSTFLAGS is used by Cargo and always passed to the compiler. Put our
non-standard crate_hash argument there because it is required for
reproducible builds.
Add the rpath option to avoid having to patch Cargo.toml for this and
remove the function that does so.
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
rust-bin.bbclass now only contains what is necessary to build crates
using the rust compiler directly and rust.bbclass contains information
shared between rust-bin and cargo.
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>