* Convert to new override syntax
This is the result of automated script (0.9.0) conversion:
oe-core/scripts/contrib/convert-overrides.py .
converting the metadata to use ":" as the override character instead of "_".
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* Manually fix the conversion
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* layer.conf: Update layer compatibility with only dunfell and newer.
Add honister to mark the layers as compatible with honister now that it uses
the new override syntax.
Drop zeus and older which are missing a support for newer override syntax which
was backported only to 1.46 branch (used by dunfell) and newer, e.g.:
https://git.openembedded.org/bitbake/commit/?h=1.46&id=c5418eae56cc50dbae7951c055434a0c456c53a4
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* CI: use YOCTO_BRANCH instead of yocto-${YOCTO_VERSION} for poky checkout
* using latest revision in branch is often better than sticking to
some point releases
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* CI: switch to hardknott branch
* gatesgarth is already EOL, better to use something supported
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* nativesdk: Add some tools in a separate recipe
This brings ATM:
- clippy
- rustfmt
Another approach might be to include these into the existing rust recipe,
but as we can't really use PACKAGECONFIG here it might just overload it.
This way, the tools will be built in parallel and still can be excluded
from the packgae group, if desired.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
Recent versions of cargo support always showing the progress indicator.
By default the progress indicator is hidden if the output is not a tty.
For bitbake builds, the output is redirected to a file and not a tty.
However, if we tell cargo to always show the progress indicator, bitbake
can parse it and will show the user how the rust build is progressing.
This addition closes#236 requesting the SDK support. The implementation
consists on a yet minimum set of worky functionality;
- Includes rustc, rustdoc and cargo.
- Includes libstd and accompanying lib archives for host and for target.
- Integrates with the standard environment setup script.
- Integrates configurations automatically build for target.
The supported build host is still AMD64 only.
Note that there's no need on introducing crosssdk package as the
official snapshot package serves same way as a non SDK build.
Possible future directions:
- Offline build:
- Support pre-cached set of crates that can be vendored.
- Support pre-filled cargo registry.
- Support further tools like cargo-fmt, cargo-clippy, GDB support and so
on.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
Normally all *-native packages needs to depend on cargo-native in order
to be able to use cargo. When building cargo-native however, this is not
available and we use a snapshot.
Fixes#302.
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>
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.
This solves SSL CA cert errors.
When a sstate-cache is used sometimes the certificates are not available
at the compile time path anymore. The required certificates are
available in sysroot-native and can be selected with the cainfo
configuration.
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.
Before the flag was stabilized, it required two arguments of the form
"from=<from_path>" and "to=<to_path>" respectively. The stabilized
version uses one argument of the form "<from_path>=<to_path>".
Unfortunately the old format is still parsed successfully, but results
in attempting to replace the literal paths "from" and "to".
https://github.com/rust-lang/rust/issues/41555#issuecomment-320951103
Further changes needed for musl to work.
env needs to be set to "musl" for unwinding work properly.
Also the llvm target should end with "-musl" and not "-gnu".
Because devtool inhibits all the normal bitbake fetchers, we can't mask crates.io.
Use EXTERNALSRC to detect if we're being built with devtool, and only mask
crates.io if we're not.
Fixes#195
Patchelf should be reserved for when the ELF cannot be generated
correctly in the first place. This is not the case here because we have
control over the linker flags. The limitation is that -C link-args can
only be specified once, so consolidate the generation of link-args. Also
introduce some new intermediate variables in link-args generation for
customization.
Patchelf was running only in ${PKGD} because patching the ELF in ${D}
would cause objcopy to fail when splitting the debug sections. This is
not a problem when setting it correctly in the linker. The benefit is
that the rpath is correct in the sysroot as well.
This also switches the rpaths to be relative so that they work in both
the sysroot and the target in the same way.
Signed-off-by: Tyler Hall <tyler.hall@lexmark.com>
Signed-off-by: Steven Walter <swalter@lexmark.com>
Commit 864fe95 ("classes: create proper compiler and linker wrappers")
introduced wrapper scripts for the OE toolchain. Specifying the sysroot
manually ceased to function in rust-bin, so use the wrapper where rustc
is called directly.
This should be more reliable than trying to repeat what OE puts in the
$CC variable.
Since commit 06a138a ("rust: drop custom target finding patch"), rustc
is no longer self-sufficient in finding its target specifications. Any
usage of rustc needs RUST_TARGET_PATH set in the environment.
Move the declaration to rust-common.bbclass and add the export to
rust-bin where rustc is invoked.
Switch the build process to using Rust's new build system called
rustbuild. At the same time stop using jemalloc on all platforms and
switch to the system allocator since that was simplier to do.
rustbuild is a cargo based way to build Rust but all of our helper bits
in cargo.bbclass would create a chicken/egg issue with dependencies
since we pull down pre-built binaries and use those for boot strapping.
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.
