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: 6eeb832f73ffb48f5f05dc47191f60e4599e640f)
Signed-off-by: Pedro Silva Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although rust differs between compiling (--> 'rust-cc' wrapper) and
linking (--> 'rust-ccld' wrapper), some core crates are using only the
'rust-cc' wrapper to check for available compiler options [1] and
libraries [2].
Not having LDFLAGS can break the build in subtle ways. E.g. 'cargo-native'
can fail to build with
| = note: .../hosttools/ld: .../liblibz_sys-....rlib(deflate.o):
| relocation R_X86_64_32S against hidden symbol `_length_code' can not be used when making a PIE object
because it does not find '-lz' (added by "DEPENDS = zlib") and builds
a static libz.a with missing PIC flags.
Add LDFLAGS to the 'build-rust-cc' wrapper as it is done already for
the target one.
[1] https://github.com/rust-lang/cc-rs/pull/1322
[2] 12a32798c6/build.rs (L228-L234)
(From OE-Core rev: 49b37575b548f0ab082c700f91fdd856740dc829)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
All of these variables are single-valued, so we can use weak-defaults
for them and only see the final assignment after parsing.
(From OE-Core rev: 3221e82a35a149fdf38fe66dcd5de758ac1b9185)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This needs to be done for any item that is linked under rustc,
and not just rust itself. Latest python-cryptography exposes the issue.
(From OE-Core rev: d3811228747590ea06e8d68be4785d45ec9c478f)
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>
Rust targets have the form of 'arch-unknown-linux-gnu' while
oe's native targets are 'arch-linux-gnu', e.g. omit the vendor.
The effect this has on rust-native builds is that rust first builds
itself as stage0 for arch-unknown-linux-gnu, then builds itself
again for arch-unknown-linux-gnu, then finally uses the compiler
from second step to 'cross-compile' a compiler for 'arch-linux-gnu'.
This last step is really not necessary, and we could save 4 minutes
out of 12 if it is eliminated. Which is what this patch does
by setting the target directly to 'arch-unknown-linux-gnu'; rust's
build system then shortcuts the build process after the second step.
Given a working rust-native will be needed as early as possible in a
typical yocto build (e.g. when in a not too distant future making a
useful kernel will not be possible without rust), producing it faster
is important.
(From OE-Core rev: a918ea5645d8a67cedaf3ecf6c382520bbcad85b)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
